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(57) Abstract 



A system for monitoring and configuring germing devices interconnected over a hi^-speed network is disclosed. The system can 
support a file server, one or more floor controllers, one or more pit termiruds^ and other terminals all interconnected over the network. 
Each gaming device includes an electronic module which allows the gaming device to conununicate with a floor controll^ over a current 
loop network. The electronic module includes a player tracking module and a data communication node. The player tracking module 
includes a card reader for detecting a player tracking card inserted therein which identifies the player. The data conununication node 
conmumicates with both the floor controller and the gaming device. The data conmiunicadon node ccmimunicates widi the gaming device 
over a serial interface through which the data communication node transmits reconfiguratlcm commands. The gaming device reconfigures its 
payout schedule responsive to die reconfiguradon commarKis to provide a variety of promotional bemuses such as multiple jackpot bonuses, 
mystery jackpot bonuses, progressive jackpot bonuses, or player specific bonuses. 
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COMPUTER NETWORK FOR 
CONTROLLING AND MONITORING GAMING DEVICES 

BACKGROUND OF THE INVENTION 

This invention relates generally to gaming devices, and more particularly to 
a method and apparatus for controlling gaming devices interconnected by a 
computer network. 

Netwoiked gaming devices are know in the ait* Interconnecting a plurality 
of gaming devices such as slot machines via a computer network to a central 
computer provides many advantages. The primary advantage of networked 
gaming devices is the ability to extract accounting data from the individual 
gaming devices as well as providing player tracking. An example of a data 
collection system is described in U.S. Patent No. 4,283 J09 issued to Lucero et al. 
Network systems such as described in Lucero et al. allow the central host 
computer to monitor the usage and payout, colleaively known as audit data, of 
the individual gaming devices. This audit data includes data related to the number 
of coins or tokens inserted into the device, the number of tinnes the device has 
been played, the amount paid in raises, the number and the type of jackpots paid 
by the machine, the number of door openings, etc. The host computer can then 
compile an accounting report based on the audit data from each of the individual 
gaming devices. This report can then be used by management, for example, to 
assess the profitability of the individual gaming devices. 

Player tracking, as the name indicates, involves tracking individual player 
usage of gaming devices. In prior art player tracking systems, the player is issued 
a player identification card which has encoded thereon a player identification 
number that uniquely identifies the player. The individual gaming devices are 
fitted with a card reader, into which the player inserts a player tracking card prior 
to playing the associated gaming device. The card reader reads the player 
identification number off the card and informs a central conq>uter connected 
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thereto of the play^'s subsequent gaining activity. By tracking the individual 
players, individual player usage can be monitored by associating certain of the 
audit data with the player identification numbers. This allows gaming 
establishments to target individual players with direct mariceting techniques 

5 according to the individual's usage. 

One problem that can occur with current player tracking systems is that the 
player can insert a player identification card incorrectly unbeknownst to the 
player. Cunendy, if a player inserts a player identification card improperly into 
the card reader, a message appears on a display located away from the card 

10 reader. Unfortunately, the player may not be looking at the display while 

inserting the card. As a result, the player may not see the message on the display. 
Another prior art approach has been to provide a light emitting diode on the 
gaming device to indicate to the player the status of the card insertion. This too 
has been ineffective because the player may not know the purpose of the LED or 

15 the LED may be drowned out by all the other lights of the casino. The player may 

therefore commence playing with the card improperly inserted. In this case, both 
the player and the casino lose valuable player tracking information. This is 
frustrating for the player because his activity will not be credited to his account 
and frustrating for the casino because the casino's records will be inconq>lete. 

20 Accordingly, a need remains for an improved method and ^paratus for informing 

the play^ when a player tracking card has been improperly inserted. 

The full power of networked gaming devices has not been completely 
realized. Although the audit data indicates which devices are being under utilized 
and when, there is currently no automated method for altering under utilized 

25 gaming devices' configurations to make them more attractive to play. For 

example, during certain hours of the day, e.g. four to six a.m., the audit data may 
indicate that the machines are being under utilized. Thus, it would be desirable to 
reconfigure the under utilized gaming devices to provide an additional incentive 
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to players to use these devices. In the past casinos have ran ''bonuses" during 
these times. An example of such bonuses include a "double jackpof whmin a 
player hitting a jackpot is paid double the jackpot amount. Cuirently this is 
implemented by having an attendant manually payout the additional payout 
amount. This manual technique, however, is cumbersome and inefficient to 
administer because an attendant must be constantly supervising the bonusing 
gaming devices. Accordingly, a need lenuiins for an automated method and 
^paratus to provide bonusing for gaming devices. 

Another limitation of the cunent bonusing systems is that only 
predetemiined machines are eligible for the bonusing. For example, in a 
progressive bonusing machine a plurality of machines are connected together to 
form a bank. Only the machines in the bank are then eligible to win the 
progressive jackpot. Thus, a casino must dedicate a certain number of its 
machines to these banks. This limits the castno*s flexibility in tailoring its 
bonusing to the number and make-up of its customers. Accordingly, a need 
remains for a more flexible bonusing system whereby any of the casino's 
machines can participate in the bonusing. 

SUMMARY OF THE INVENTION 

It is, therefore, an object of the invention to reconfigure gaming devices 
remotely over a network to provide bonusing. 

Another object of the invention is to provide an integrated system usable 
with a variety of gaming ctevices made by different manufacturers. 

Another object of the invention is to integrate player tracking, data 
collection, and bonusing over the same network. 

A further object of the invention is to provide visual feedback to the user 
when a player tracking card has been improperly inserted. 

A system for operating netwoiked gaming devices is described. The system 
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s>£conilioiig to ttte mvesntioini sllows & cmmo in which the sys^m ns instiled to mn 
promQ»(t&oiniS or bostiases on my ptop^dy ^quippod gmmng machines wMle 
simiaitSi!nt©otiislly gsitlh^rmg pkyeir mi^iisg md sicconaintmg daita firoM asll machicnes. 
The systtem pmvides (the cffipsibiEJy for (ths cffisisno So select which of (the pluiffality 

S of macMin^s med m smy given prosmioticm. The system fuather allows my 

mwt^T of different promotions to opemte simultaneously. 

The system includes a plundity of gaming devices or machines connected 
to an associated floor controller over a network. The system includes one or more 
of said floor controllers. The floor controllers aire interconnected by a high-speed 

10 neMork, such as an Ethernet networEc, to a database whese accounting and player 

tracking data ns stos^. The system can also include pit terminals and/or flil and 
jackpot processing terminals. 

Bach promotion involves sending a ireconflguration command from th^ 
floor controller to a gaming device timt has been selected to be part of a given 

15 promotion over the associated metwoik. Upon receipt of the meconfiguration 

command, the gaming device seco^figus^ its payout schedule in accordance with 
the received ireconfiguration command. In the preferred embodiment, this 
meconflguration includes activating a bonus payout schedule. A partial list of the 
promotions according to the invention include, but are not liEnited to: a multiple 

20 jackpot wherein the gaming device ireconfigures its payout to be a multiple of its 

default payout schedule; a bonus jackpot wherein the gaming device ireconfigures 
its paymit schediLale to payout an additional bonus anmunt w^n certain conditions 
are m^; and a progressive jackpot wherein two or more gaming devices are 
combined in a progressive jackpot having a progressive jackpot payout schedule. 

25 In addition to these, many (^her p:omotions are possible by the above-described 

system for controlling and monitoring a plurality of ganoing devices. 

The system also allows for improved player tracking by recording each and 
every snachine transaction including time of play, nmchine nuimber, duration of 
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play, coins in, coins out hand paid jackpots and games played. The player 
tracking is conducted over the same netwoik as the accounting data is extracted. 
This allows the invention to provide bonusing to certain individual players as well 
as during ceitain times. As with standard player tracking, the above-described 
system monitors and reports how many coins are played by each player. The 
system according to the invention, however, also includes the ability to record 
how long each player spends at each machine and the number of coins won, 
games played, and hand jackpots won by each player. The invention is able to 
record all this information because the system operates on a transaction by 
transaction basis. Each transaction, whether it be a coin in, a handle pull, etc., is 
recorded by the system. Other systems simply compile the player tracking 
information at the completion of play. All this information is stored on the 
database, which can be later analyzed for future targeted direct mailing 
campaigns. The player tracking according to the invention also allows the casino 
to schedule buses and other groups and measure their profitability. The system 
also allows for cashless play as well as advanced accounting and security features. 

An advantage of the invention is that any of the casino* s machines can be 
incorporated into a bonus promotion. 

Another advantage of the invention is that several bonus pronK>tion$ can 
operate simultaneously. 

A further advantage of the invention is the ability to record each and every 
machine transaction including time of play, machine number, duration of play, 
coins in, coins out, hand paid jackpots and games played. 

A further advantage of the invention is the ability to associate a player with 
a certain machine. 

A further advantage of the invention is the ability to perform more targeted 
direct mailing based on individual play. 

A further advantage of the invention is the ability to calculate a theoretical 
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win exactly. 

A fiirthN advantage of the invention is the ability to generate jackpot 
announcements, which provides for, aroong other things, better slot touraaments. 

A yet further advantage of the invention is the ability to quickly and easily 
add new nuichines to the network. 

The foregoing and other objects, features and advantages of the invention 
will become more readily apparent from the following detailed description of a 
preferred embodiment of the invention which proceeds with reference to the 
accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. I is an illustration of a system for monitoring and configuring gaming 
devices according to the invention. 

FIG. 2 is a block diagram of an electronic module associated with each 
gaming device to permit monitoring and configuring thereof. 

FIG. 3 is a schematic diagram of a data communication node of the 
electronic module of FIG. 2. 

FIG. 4 is a schematic diagram of a discrete machine interface circuit of the 
electronic module of FIG. 2. 

FIG. 5 is a schematic diagram of a player tracking module of tte electronic 
module of FIG. 2. 

FIG. 6 is a schematic diagram of a card reader circuit of the electronic 
nuxlule of FIG. 2. 

FIG. 7A is an exploded view of a card reader according to the invention. 

FIG. 7B is a rear perspective view of the card reader of FIG. 7A. 

FIG. 7C is a front perspective view of the card reader of FIG. 7A. 

FIG. 8 is a schematic diagram of a display circuit of the player tracking 
HKxlule of FIG. 2. 
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FIG. 9 is a schematic diagram of a personality board of the electronic 
module of FIG. 2. 

FIG. 10 is a schematic diagram of a triac driver circuit of the electronic 
module ofHG. 2. 

FIG. 1 1 is a schematic diagram of a relay driver circuit of the electronic 
module of FIG. 2. 

FIG. 12 is a block diagram of a communication board included in each 
floor controller of FIG. 1 . 

FIG. 13 is a flow chart for the power-on procedure for the data 
communication node (DCN) of FIG. 2, which is implemented in firmware 
executed by the DCN controller. 

FIG. 14 is a flow chart for processing of the discrete gaming device inputs, 
OfHG. 13. 

FIG. 15 is a flow chait for the step of incrennenting meter counts associated 
with each gaming device of FIG. 14, which is implemented in flrmwaie executed 
by the DCN controller. 

FIG. 16 is a flow chart for the step of processing the serial interface 
between the gaming device and the data communication node of FIG. 13, which is 
implemented in flrmware executed by the DCN controller. 

FIG. 17 is a flow chart for the step of processing the network interface, 
between the floor controller and the data communication node of FIG. 13, which 
is implemented in flrmware executed by the DCN controller. 

FIG. 18 is a flow chart for the step of processing the network message of 
HG. 17, which is implemented in flrmware executed by the DCN controller. 

FIG. 19 is a flow chart for the step of processing the data conmiunication 
node request of FIG. 18, which is implemented in flrmware executed by the DCN 
controller. 

FIG. 20 is a flow chart for the step of FIG. 13 of processing the player 
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tracking interface, which is implemented in firmware executed by the DCN 
controUen 

FIG. 21 is a flow chart for the step of processing a valid inserted card of 
FIG. 20, which is implemented in firmware executed by the DCN controller. 

FIG. 22 is a flow chart for the step of processing player tracking 
infomiation of FIG. 21, which is implemented in firmware executed by the E)CN 
controller. 

FIG. 23 is a flowxhart for the power-on procedure for the player tracking 
(FT) node of FIG. 2, which is implemented in firmware executed by the PT 
controller. 

FIG. 24 is a flow chart for the step of processing the £>CN interface of FIG. 

23, which is implemented in firmware executed by the PT controller. 

FIG. 25 is a flow chart for the step of processing the DCN message of FIG. 

24, which is implemented in fimiware executed by the PT controller. 

FIG. 26 is a flow chart for the step of processing the card reader bezel 
update of FIG. 23. which is implemented in firmware executed by the PT 
controller. 

FIG. 27 is a flow chart for the step of processing the card reader of FIG. 23, 
which is implemented in firmware executed by the PT controller. 

FIG. 28 is a flow chart for the power-on floor controller process, which is 
implemented in software executed by the floor controller. 

FIG. 29 is a flow chart for the message processing step of FIG. 28, which is 
inq[>lemented in software executed by the floor controller. 

FIG. 30 is a flow chart for Hic message handling step of FIG. 29, which is 
implemented in software executed by the floor controller. 

FIG. 31 is a flow chart for the step of assigning unique machine addresses 
of FIG. 30, which is implemented in software executed by the floor controller. 

FIG. 32 is a flow chart for the system nK)nitoring step of FIG. 28, which is 
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implemented in software executed by the floor controller. 

FIG. 33 is a flow chart for the event handling step of FIG. 32, which is 
implemented in software executed by the floor controller. 

FIG. 34 is a flow chart for bonus control, which is implemented in software 
executed by the floor controller. 

DETAILED DESCRIPTION 

Table of rnnfents 

I. SYSTEM ORGANIZATION 

A. SYSTEM OVERVIEW 

B. DATA COMMUNICATION NODE 

1. Overview 

2. Controller and Memory 

3. Network Interface 

4. Serial Machine Interface 

5. Serial Display Interface 

6. Discrete Machine Interface 

7. Machine Configuration 

C. PLAYER TRACKING MODULE 

1. Overview 

2. Serial Display Qrcutt 

3. Serial Expansion Ports 

4. Card Reader 

5. Display 

6. Discrete Input Section 
p. PERSONALITY BOARD 
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E. BONUS DISPLAY DRIVERS 

F. FLOOR CONTROLLER 
II. OPERATION 

A. DATA COMMUNICATION NODE 
5 1. POWER Up Procedure 

2. Reading Unique Identircation number 

3. Monitoring Gaming Device Discrete Input 

4. Processing Gaming Device Serial Interface 

5. Processing Network Interface 

10 6. Processing Player Tracking Interface 

7. Processing Card Insertion 

B. PLAYER TRACKING MODULE 

1 . Power Up Procedure 

2. Processing DCN Interface 
15 3. Processing Dismjvy Update 

4. Processing Bezel Update 

5. Processing Card Reader 

C. FLOOR CONTROLLER 

I . Power Up Procedure 
20 2. Message Processing 

3. Assigning Gaming Device Addresses 

4. SYSTEM MONITORING 

5. Bonus control 
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I. SYSTEM ORGANIZATION 
A. SYSTEM OVERVIEW 

A system for operating a plurality of gaming devices is shown generally at 
10 in FIG, 1. The system, hereinafter described, monitors and reconfigures a 
plurality of gaming devices or machines 12-16 and 22-26. The system includes 
the following capabilities: remote reconfiguration, accounting data extraction, 
integrated player tracking, and cashless play* Remote reconfiguration includes 
sending a reconfiguration conunand from a host computer to one or more of the 
gaming devices. The gaming devices, on receiving a reconfiguration conmuind, 
will reconfigure its jackpot payout schedule in accordance with the 
reconfiguration command. 

This reconfiguration, in the preferred embodiment, comprises activating a 
bonus payout schedule. This bonus payout schedule is in addition to the normal 
pay table of the gaming device. The bonus payout schedule provides for 
additional bonus payouts in addition to the payouts specified by the device's 
normal pay table. The difference between the two is important for regulatory 
reasons. The composition of the pay table is subject to regulation by the various 
state gaming conunissions while the bonus payout schedule is not. The preferred 
embodiment currently activates only the bonus payout schedule responsive to the 
reconfiguration conunand, while not altering the payout table. The invention, 
however, is not limited to activating only the bonus payout schedule. Other 
embodiments, which would be subject to regulatory approval, could nKxiify the 
device*s payout table. The prefened embodiment, however, does not. 

The system, according to the invention, implements a variety of bonusing 
events through this reconfiguration process. These bonusing events include: a 
multiple jackpot wherein the gaming device reconfigures its payout to be a 
multiple of its default payout schedule; a bonus jackpot wherein the gaming 
device reconfigures its payout schedule to payout an additional bonus amount 
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whera ceHltffim conditions siare met; md & progmgssive jaicIcpot.wheieiE two or more 
gamimg dtevaces arc combmed in a progmessive jackpot having a progmessi ve 
jackpot payout schisdijile. 

Th© system, according to the invention, also provides for integrated player 
tracking and accounting data extraction. Unlike prior art systems that me 
disparate systems for player tracking and accounting data extraction, the system 
10 provides for player tracking and accounting data extraction over the sam^ 
network. The player tracking, according to tihe invention, allows the casino to ran 
cextain poHBOtionall events. TIte integrated player tracking and accounting data 
extraction also allows the system to susppon cashless pSay wherein a credit is 
given to a player over the network. 

The system 10 includes one or more floor controllers 18 and 28. Each floor 
controller supports up to a predetterHnined maximum number of ganming devices. 
In the preferred embodiment, each floor controller can support up to 1024 gaming 
(tevices. The preferred embodiment also suppom up to eight floor controlers. 
Thus, the system 10 can support up to 8192 separate garaiing devices. 

The system supports a multiplicity of various gaming devices. The gaming 
devices 12-16 and 22-26 shown in FIG. 1 are the type having a puU handle for 
initiating a game, e.g., slot machines. However, the invention is not limited to 
such gaming devices. The gaming devices shown in FIG. 1 can also be gasning 
tables or push button operated machines as well, e.g, video poker. As will be 
desmbsd hereinafter, tite system supports any gaming device providing 
traditional discrete connections, e.g., coins-in, coins-out, etc., as well as those 
having serial interfaces, as described below. 

The floor controllers 18 and 28 are, in the preferred embodimrat, IBM- 
comipatible personal computers. Each floor controller is responsible for 
monitoring ^ activity level of the corresponding gaming devices connected 
thereto and issuing commands to the associated gaming devices to reconfigure 
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iheir payout scheddes dmng certasE boaummg eveints. The floor coatrollcrs issue 
sMuts iT^ueste to each of mdividual gamixng devices to deJeomime (the activity 
level of each. In the eveet the floor controller detects aiuy activity, the floor 
coEtroller communicates that activity to a file server 32, which is coniniected to the 
floor coDitffoUers via a high speed iietwoirk 38 connected therebetween. 

In the pieferred embodiment, the file server 32 includes a high performance 
personal computer or work station having a large hard disk capacity in order to 
store the gaming device activity thei^in. In the pmefenred embodiment, the high 
speed network 38 is a ten megabyte etthemet network. The system 10 also 
includes commercially available network softwair© to support tite industsy- 
standard ethemett network 38. An example of such network solRtware is Novell 
netwoirk software sold by Novell of Pmovo, Utah. The flie server 32 also includes 
a database program by which reports can be generated using the data stored on the 
file server. Such reports include, e.g. area, model, denomination and sunwrnry 
seports. The database software also allows a user to generate custom reports. The 
database software is based on the industry-standard Paradox database language. 

The system 10 also includes a pit terminal 34 which is also c^mnected to the 
eltemet network 38. The pit terminal 34 is also a standard personal computer, in 
the preferred embodimont, and can be used to monitor the gaming device activity 
in the pit. This terminal 34 

can also be used as a security monitoring device to detect any unanticipated 
events like fills or payouts. 

The system 10 further includes any number of fill and jackpot processing 
terminals 36. These terminals 36 are placed in the cage and/or the change booth 
areas of the casino for fill and hand-paid jackpot processing. When a fill is 
required, a floor person goes to the nearest cashier's booth and states th^ gaming 
device number sequiring a fill. The booth attendant enters the number into the fill 
and jackpot processing terminal 36 located in the cashier's booth. The terminal 
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36 then k>oks up the record associated with the particular gaming device in the 
file server 32 to determine the conect fill amount. The temiinal 36 also calculates 
a theoretical hopper balance for the particular device based on the latest meter 
infomiation, as described further below. If the calculation shows a significant 
hopper balance* a warning is given on the computer screen from which security 
can then be alerted. 

A fill and jackpot processing temiinal 36 prints a fill ticket upon demand. 
If the calculated hopper balance was neariy zero, the terminal 36 cause the words 
"computer verified" to be printed on the ticket in place of a supervisor's signature. 
In the event that the calculated hopper balance was not near zero, an extra 
signature is required to complete the fill transaction. The system follows a similar 
procedure for processing hand-paid jackpots. 

A dispatch station (not shown) can also be included in the system. The 
dispatch station allows the casino to monitor activity on the gaming devices and 
"run the casino" from one location. The dispatch station allows the dispatcher to 
monitor customer service, nuiintenance, and security events and direct other 
casino personnel to handle these situations appropriately. For example, during 
hopper empties (fills) and jackpot events, as indicated by the dispatcher station, 
the dispatcher could radio down to the floor to have someone verify the event 
The dispatcher station can also indicate when a machine door is opened without a 
technician card inserted, for example, in which case the dispatcher could take the 
appropriate course of action. 

The above-described system 10 is but one embodiment of the system 
according to the invention. The system tasks can be allocated in a variety of ways 
amongst the system computers including floor controllers 18 and 28, file server 
32, pit terminal 34 and fill and jackpot terminals 36. In some cases, the pit 
terminal 34 and fill and jackpot terminals 36 can even be eliminated and their 
tasks allocated to the floor controller or file server. In fact, because the file server 
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32 is essentially a virtual hard disk for the floor controllers 18 and 32« the floor 
controllers and the file server can be considered a single host computer for the 
system 10. 

B. DATA COMMUNICATION NODE 

1. Overview 

In order to conununicate with the floor controller, each gaming device 
includes therein an electronic nKxluIe 40, as shown in FIG. 2. This module 40 can 
be inserted into a variety of pre-existing gaming devices. The module allows the 
host con4>uter to uniquely identify the gaming device on the netwoik, including 
the device type. The module 40 includes two main subcomponents: a data 
conununication node 42 and a player tracking module 44. The data 
conununication node 42 keeps track of the coins*in, coins-out, coins to drop, 
games played, jackpot occurrences and other related functions of the associated 
gaming device. The player tracking module 44 keeps track of the player that is 
playing the associated gaming device. Together, the data conununication node 42 
and the player tracking module 44 allow the floor controller connected to the 
associated gaming device to monitor and control the activity of the gaming 
device. The system hereinafter described in detail includes the following 
capabilities: slot accounting, player tracking, bonus jackpots and cashless play. 

2. Controller and Memory 

The data conununication node (DCN) 42 includes a data conununication 
node controller 46, which in the preferred embodiment is an HD64732S8P10 
controller manufactured by Hitachi of Tokyo, Japan. The DCN 42 is coupled to 
the player tracking controller 44 through bus interface logic 45* The bus interface 
logic 45 is conventional interface logic including, for example, transceivers, as is 
known in the art of digital design. 

A memory 48 is connected to the DCN controller 46. The memory 
includes program memory for storing program instructions for the DCN controller 
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46. In the piefenned embodiment, this program memory includes a nonvolatile 
read*only memory (ROM). However, this program memory could also be flash or 
"battery** backed RAM in order for the program memory to be updated by the 
floor controller. In the event flash or "battery** back RAM is used the floor 
controller would download the updated program to the DCN controller and the 
DCN controller would overwrite the program memory with the downloaded 
program. 

The memory 48 also includes system memory, e.g., static random-access 
memory (SRAM) for storing the gaming device information. This gaining device 
information includes at least the following meters: coins-in, coins-out, coins to 
drop, games played, jackpot occurrences. A separate meter counter is kept in 
memory 48 for each of these values. To increase reliability of the data, in the 
preferred embodiment, a redundant set of these counters is kept in a physically 
separate menK>ry device within memory 48. Moreover, the memory devices 
storing these counters are nonvolatile so that in the event of a power failure the 
counts will be retained. The nonvolatile memories can either be battery-backed 
SRAM or electrically erasable programmable read-only memory (EEPROM). 
Although memory 48 is shown external to DCN controller 46, much if not all of 
the memory 48 can be included in the DCN controller 46. 
3. Network Interface 

The data conmiunication node 42 also includes a network interface 49 for 
connecting the data communication node 42 to the associated floor controller* 
The network interface is coupled to die floor controller through a personality 
board 2Q2, desoibed below* 

A more detailed drawing of networic interface 49 is shown in FIG. 3* In 
HG. 3, the DCN controller 46 receives data firom the floor controller over 
conductor 52 whidi is optically isolated flom a connector 51 by optical isolator 
circuit 54* The DCN controller 46 transmits data to the floor controller over 
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conductor 56, which is optically isolated from the connector 51 by optical isolator 
circuit 58, Each of the opto-isolator circuits 54 and 58 include an opto-coupler as 
are known in the art. A bus 222 (FIG. 2) is connected between the network 
interface 49 and the personality board 202. 

4. Serial Machine Interface 

Referring to FIG. 2, the data communication node includes a serial machine 
interface 60. The serial machine interface 60 allows the data communication 
node 42 to communicate with the associated gaming device advance serial 
interface as contrasted with the discrete interface, to be described further 
hereinafter. A bus 224 (FIG. 2) connects the serial machine interface 60 to the 
associated gaming device at connector 62. The serial interface, in the preferred 
embodiment, is a standard RS-232 three wire interface. 

Referring to FIG. 3, the DCN controller 46 receives data from the gaming 
device over conductor 64 which is connected between the DCN controller 46 and 
a differential to single-ended converter 66. The DCN controller 46 transmits data 
to the gaming device over conductor 68 connected between the DCN controller 46 
and the converter 66. The converter 66 converts the differential inputs of the 
serial interface 62 to a single-mded output which is transmitted over conductor 64 
to the DCN controller 46. The converter 66 also converts the single-ended input 
received from the DCN controller 46 to a differential output signal and transmits 
that to the serial interface 62. The serial machine interface is the means by which 
the DCN controller communicates certain reconfiguration data, referred to as 
reconfiguration commands, to the machine. These reconfiguration commands 
cause the machines to activate a bonus payout table to allow the machine to 
q)pend bonus payments to their standard jackpot payouts, as specified by their 
payout table, during certain bonus activities. 

5. Serial Display Interface 

The data communication node 42 further includes a serial display interface 
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70 illustrated in more detail in FIG. 3. The serial display interface 70 includes 
logic coupled between the DCN controller 46 and an expansion connector 71. 
The expansion connector 71 allows the DCN controller 46 to communicate with 
an expansion device connected thereto. 

6. Discrete Machine Interface 

The data conununication node 42 also includes a discrete machine interface 
72, which is shown in detail in FIG. 4. The discrete machine interface 72 includes 
a plurality of opto-couplers 78 coupled between the discrete outputs from the 
gaming device or machine and the DCN controller 46. The discrete outputs of the 
machine are received at terminals 74A-74J of a connector 74 via a cable (not 
shown) connected between the machine and the connector 74. The discrete 
outputs are coupled to corresponding inputs 76A-76J via opto-couplers 78. The 
discrete outputs from the machine include: an EXTRA signal, a POWER signal, 
a COIN IN signal, a COIN OUT signal, a COIN DROP signal, a JACKPOT 
signal, a HANDLE signal, a TILT signal, a SLOT DOOR signal, and a DROP 
DOOR signal. Each of these signals correspond to a known event in the machine. 
For example, when a coin is dropped in the machine a COIN IN signal appears on 
terminal 74C. This COIN IN signal is then transmitted to the DCN controller 46 
on line 76C via the associated opto-coupler. 

All of the signal lines 76A-76J include a pullup resistor and a pulldown 
capacitor, which combiiwd form an RC network on the associated line. The 
resistors are, in the preferred embodiment, in the form of a resistor pack 80 and 
the c^acitors are individual discrete capacitors 82. Alternatively, the capacitors 
can be removed for high-speed signals. 

7. Machine COnhguration Qrciot 

The data communication node 42, as shown in FIGS. 2 and 3, further 
includes a machine configuration circuit 84. In the preferred embodiment, as 
shown in FIG. 3. the machine configuration circuit 84 includes a parallel to serial 
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converter 86» which includes eight parallel inputs IN, a serial input SIN, a clock 
input CLK, a strobe input STB, and a serial output SOUT. The parallel inputs IN 
are connected to a personality board, as described hereinafter, to receive a unique 
machine configiiration number therefrom, which uniquely identifies the type of 

5 machine that the data conmiunication node is connected to. In the preferred 

embodiment, the machine identification number is comprised of six bits. 
Therefore, the two remaining parallel inputs can be used to provide additional 
inputs, such as additional discrete machine inputs, to the DCN controller 46. 
The machine configuration number presented on the parallel inputs of the 

1 0 parallel to serial conv^ter 86 is latched therein responsive to a strobe signal 

received at the strobe STB input. A strobe input is generated by the DCN 
controller 46 on conductor 90 which is coupled to the strobe STB input. The 
parallel data is clocked out of the converter 86 to the DCN controller 46 on 
conductor 88 and connected between the serial output SOUT of the converter 86 

15 and an input of the DCN controller 46 responsive to a clock signal received on the 

clock input CLK of the converter 86. The clock signal is generated by the DCN 
controller 46 and is transmitted to the converter 86 via conductor 92 which is 
coupled between an output of the DCN controller 46 and the clock input CLK of 
the converter 86. 

20 The converter 86 also includes a serial input SIN for receiving serial input 

data. The serial input SIN is coupled to an expansion terminal 94C of expansion 
connector 94. Conductors 90 and 92 are also coupled to the expansion terminal 
94 to provide the clock and strobe signals thereto. The expansion terminal 94 
thmfore provides the means for the DCN controller 46 to access additional serial 

25 information through the parallel to serial converter 86. In the preferred 

embodiment, the parallel to serial converter 86 is part number 4021 manufactured 
by Toshiba Corporation of Tokyo, Japan. 
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C. PLAYER TRACKING MODULE 

1. Overview 

Referring again to FIG. 2. the module 40 coupled to each of the gaming 
devices includes a player tracking module 44. The player tracking (PT) module 

5 44 includes a player tracking controller 98. a card reader 100, a serial display 

driver 101, a display 102, and expansion interfaces 104 and 106. The player 
tracking controller 98 conmiunicates with the data communication node controller 
46 through bus interface logic 1 10. The DCN controller 46 and PT controller 98 
maintain a master-slave relationship, respectively. Therefore, all communication 

10 is initiated by the DCN controller 46. The bus interface logic is conventional 

logic and its design is well-known in the art of digital electronics. 

In the preferred embodiment, the player tracking module 44, with the 
exception of the card reader 100 and the display 102, resides on a single printed 
circuit board, while the data conmiunication node 42 resides on a separate printed 

15 circuit board. The player tracking module 44 and the data communication node 

42 are then connected by a cable 1 1 1 such as a ribbon cable. 

2. Serial Display Circuit 

A more detailed drawing of the player tracking module 44 is shown in FIG. 
5. In FIG. 5, the serial display circuit 101 includes a transistor Ql and a resistor 

20 R 1 connected to the base thereof. A conductor 1 1 2 is connected between the PT 

controller 98 and the resistor R 1 to provide a drive signal to transistor Ql . The 
drive signal causes transistor Ql to conduct a current and thereby drive a display 
connected to the collector of Ql at a terminal 1 14 of a connector IIS. In the 
preferred embodiment, the terminal 1 14 is connectable to a small vacuum 

25 florescent display to provide serial display data thereto. 

3. Serial Expansion Ports 

The player tracking module 44 also includes two serial expansion ports 104 
and 106. Each of the expansion ports 104 and 106 includes a differential to 
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single-ended converter 1 16 and 1 18, respectively. In the preferred embodiment, 
these converters 116 and 1 18 are part number LTC490 manufactured by Linear 
Technology Corporation of Milpitas, California. The PT controller 98 
conununicates with each converter via two single-ended, serial signal lines: an 
input signal line and an output signal line. The converters convert the single 
ended signals £q>pearing on these lines to differential signals. The differential 
signals, however, can be used as single-ended signals as is known in the art. The 
first expansion port 104 interfaces the player tracking node 44 with a large 
vacuum florescent display 102 (FIG. 5) used to display player tracking messages, 
as described further below. The display is connected to the connecter 1 IS, in the 
preferred embodiment, by a cable 103. The other expansion ports 106 provides 
the player tracking module with future expansion capabilities to support 
additional features. 

4. Card Reader 

Referring now to FIGS. 6 and 7, the card reader 1 00 will now be described. 
FIG. 6 shows the electrical schematic for the card reader while FIG. 7 shows the 
ntechanical drawing thereof. In FIG. 7A, an exploded view of the card reader is 
shown. The card reader includes a plastic bezel 1 16 having a card reader opening 
118 formed therealong for receiving a card 120 therein. The bezel 1 16 includes 
guide rails 122 and 124 disposed at opposite, respective lateral ends of the 
opening 118. The guide rails 122 and 124 have stops 126 and 128, respectively. 
The guide rails 122 and 124 guide the card 120 through the opening 118 until an 
end of the card 120 contacts stops 126 and 128. The card is shown fully inserted 
in FIGS. 7B and 7C with the end of die card 120 abutting the stops 126, 128. 

The card reader also includes a printed circuit board 130 having a 
longitudinal opening to allow the guide rails 122 and 124 to be inserted therein in 
mder to allow the printed circuit board 130 to be pushed up flush against a 
mounting plate 132 of the bezel 1 16, as shown in FIGS. 7B and 7C. Mounted on 
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one side off ifes prmaed circmi boaid 130 is an anray of photodiiodes 134 and an 
ainraiy off iplhiotodettectoffs 136. The photodiodes 134 are mounted on the printed 
ciffcmtt boaffd along one side of the opening in the printed circuit board, while the 
photodetectors 136 aire mountted on 4fee printed circuit board along an opposite 
side off the opening. Tbd photodiodes and the photodetectors arc vertically 
aligned in a one-to-one rclattionsMp. i.e., one photodiode for each photodetector. 
In the prcferrcd embodiment, the array of photodiodes includes eight individual 
diodes spaced equidistance along the opening in the printed circuit board 130. 
The phoiodiodes 134 arc mnounted along the opening in the printed circuit board 
130 so as to align with separate ra^ws of openings in tthe card 120, as described 
ffurtther below. The card reader also includes optional light masks 138 and 140. 
The light mask 138 is associated with the array of photodiodes 134 and has a 
plurality of openings therein, each opening corresponding to an individual 
photodiode in the array 134. Similarly, light mask 140 is associated with the 
array off photodetectors 136 and also has one opening for each of the 
photodetectors. The light mask 138 is mounted on the printed circuit board 130 
benealLh the array of photodiodes 134 along the opening in the printed circuit 
board 130. The light mask 138 is aligned with the photodetectors 134 so that the 
qjenings in the light iimask 138 are directly beneath a corresponding photodiode in 
the array. The light mask 138 minimixes the amount of light emiitted by a 
photodiode ihm can be detected by a photodetector mher than the cosresponding 
phottodefiecaor. The Bight mask 140 is mounted on top of the photodetector array 
136 so that the openings therein align with the individual photodetectors. The 
Hghtt mask 140 further eliminattes extraneous light from the photodiodes as well as 
extraneous ambient light. 

Also mounted on the printed circuit board 1 30 are a plurality of light- 
emitting diodes 142, as'shown in HG. 7C in broken line. Tim light-emitting 
diodes are mounted on a side off the printed circuit board opposite the side on 
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which the photodiodes md phoiodelectors arc mounted on. The light-emitting 
diodes 1142 arc sxioiMiited aiound the perimeter off the opemug iu the printed circuit 
board 130 m& are received in a recessed portiom 144 of the bezel 116. The light- 
emitting diodes 142 comprise a means for providing visual feedback to a user 
inserting a card 120 into th« bezel 1 16. as described further below. In the 
preferred embodiment, the light-emitting diodes 142 arc dual light-emitting 
diodes capable of producing two primary colors and a third combination color. 

Referring now to HG. 6, an electrical schematic of the card reader is 
shown. The schemtnatic includes the array of photodiodes 134 disposed along one 
side of the card reader opening 518 and the army of photodetecttors 1 36 disposed 
along the opposite side of the opening 118. In the preferred embodiment, there 
are eight photodiodes and eight corresponding photodetectors. The photodiodes 
are arranged in pairs, with the two photodiodes within each pair being connected 
in a serial fashion. The anode of the first photodiode in the pair is coupled to the 
supply voltage through resistor, while the cathode of a second photodiode in the 
pair is connected to an output of a driver circuit 144, The driver circuit, in the 
preferred embodiment, includes two open collector inverters connected in 
paralleL A signal is provided to the driver circuit 144 by ttS^ FT controller 98 
over a conductor 146, A signal on conductor 146 causes the driver circuit 144 to 
conduct current and thereby actuate the photodiodes 134 substantially 
simultaneously. 

The photodetectors 136 are comprised of a plurality of light-sensitive 
phototmnsnsttors PD1-PD8. The emittters of the phototransistors PD1-PD8 are all 
coupled to ground. The collectors of phototransistor PDl and PD8 are connected 
together and to a conductor 148 by which the FT controller 98 senses light 
detected by either phototransistor PDl or PD8. Phototransistors PD2 and PD7 arc 
simiiariy connected with the colle<^rs of each being connected to a conductor 
ISO. Tii^ collectors of phototransistors PD3 and PB6 are also commonly 
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connected to a conductor 152. The collectors of the center phototransiston PD4 
and PD5, however, are connected to separate conductors 156 and 154, 
respectively. Also connected to each of the conductors 148-156 is a 
corresponding pullup resistor. In the preferred embodiment, the pullup resistors 
are included in a resistor pack 158. Each of the conductors 148-156 are 
connected to a connector 170, which is coupled to the PT controller 98 as 
described below. 

Based on the above configuration of the phototransiston PDl and PD8, 
only five conductors are required to sample all eight of the phototransiston. 
Widiout more information, however, the player tracking controller 98 would be 
unable to determine which of the two phototransistors commonly connected to a 
particular conductor, e.g., conductor 148, detected light. For example, if either 
phototransistor PDl or phototransistor PD8 detect light, the voltage level on 
conductor 148 will drop from a high voltage of approximately 5 volts to a low 
voltage of approximately 0.7 volts. Without more information, the player 
tracking controller 98 would be unable to determine which of the two 
phototransistors. PDl or PD8. actually sensed the light. According to the 
invention, however, the card 120, as shown in FIG. 7A, includes a first slot 150 
by which the PT controller 98 can determine which of the two photodetectors 
detected the light, as described below. 

The card 120 includes five rows of slots 152-160. The rows of slots 152- 
160 are arranged in a nnatrix with the corresponding slot locations within each of 
the rows being aligned in columns. Only the first slot 150 of row 152 cannot be 
aligned with any other slots, i.e., slot 150 is in a column all by itself. The 
individual slots within the rows of slots 152-160 encode unique player tracking 
information. Each slot represents a single binary bit in the player tracking 
infcmnation. Eitho' one of two conventions can be used to encode the 
information. First, a slot can represent a binary 1 and no slot can represent a 
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bmffiiry 0. Secomd, © slot can irepiresem a bimnry 0 and no slot can mepresent a 
himsry L Tlh^ player (bracMng mfonmiitnon can include: a uniqute player 
ideniificattion niamlbeff, the casino issming the card, player membership 
infonmtion, etc. 

5 In the pireferred embodiment, the card includes five rows of slots each 

having a maximum number of nine individual slots, thereby producing 45 
possible slots. The first row of slots 152, however, is not used to encode player . 
tracking information, but instead is used to synchronize the sampling of the player 
tracMng information by the player (tracking controller 98. Thus, only 36 slots arc 

10 used to encode player tracking infomnsation in the pirefenred embodiment. This 

still allows 2^^ possible combinations, which is moie than adequate. 

The PT controller 98 uses the first row 152 to synchronize the sampling as 
follows. The FT controller 98 continuously samples the outputs of PD4 and PD5 
looking for a slot. If a slot is detected on either PD4 and PD5 and no other slots 

15 are detected by any mher phototransistors the PT controller 98 determines that the 

detected slot must be slot 150. The PT controller 98 then continuously samples 
the output of the phototransistor that detected slot 150. Once a new slot is 
detected by that phototransistor, the PT controller 98 then samples the outputs of 
the other phototransistors, i.e., PD1-PD3 and PI>6-PD8, on conductors 148, 150 

20 and 152 for slots in of the other rows. Thus, the PT controller 98 synchronizes the 

sampling of the other rows of slots to the detection of a slot in the first row 152. 

It is important for the card iPgader to detect tl^ orientation of the card in 
Older to correctly interpret the player identification information encodSed on the 
cmd. The card H^adfer detects the orientation of the card 120 by dete^ 

25 150. If slot 150 is detected by phototransistor PD4, then the card reader knows 

that the card is in the orientation shown in FIG. 7A. In that case, tl^ card reader 
knows that the player tracking information is actually being detected on 
phototransistors PD5-PD8, and can interpret the player tracking information 
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accordingly. If» however* phototransistor PDS detects slot ISO, then the card 
reader knows that the card 120 is oriented 180 degrees firom that shown in FIG. 
7A. In that case, the card reader knows that the player tracking information is 
being detected by phototransistors PD1-PD4, and can interpret the information 
accordingly. The FT controller 98 can simply transpose the player tracking 
information sensed on conductors 148-152 depending upon the detected 
orientation of the card. Thus, the card reader according to the invention is able to 
correctly interpret the player tracking information regardless of how the player 
inserts the card 120 into the bezel 1 16 of the card reader. The invention is able to 
accomplish this with only five conductors between the eight phototransistors 
PD1-PD8 and the PT controller 98. 

The card reader further includes a plurality of light-emitting diodes 142 that 
are mounted on the printed circuit board 130 and received in the recess 144 of the 
bezel 1 16, as shown in FIG. 7C. The LEDs 142 are mounted on the printed 
circuit board 130 so as to surround the card reader opening 1 18 as shown in FIG. 
6. In the preferred embodiment, the card reader includes 24 dual diodes arranged 
in pairs. The dual diodes have two separate diodes, each being able to emit a 
different primary color of light. In the preferred embodiment, the dual diodes 
emit either red or green light. The dual diodes can also emit a third combination 
color if the two individual diodes in the dual diode are actuated simultaneously so 
that the two primary colors combine. In the preferred embodiment, this 
combinatim color is approximately orange due to the differences in the intensities 
of the red and green li^t. 

The dual diodes are essentially treated as two individual diodes. The red 
dio(fes R in the dual diodes are driven by a driver circuit 162, while the gieen 
diodes G in the dual diodes are driven by another driver circuit 164. The driver 
circuits 162 and 164 are, in the preferred embodiment, two open collector drivers 
connected in parallel, as with driver 145. However, other equivalent driver 
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circuits would be q)parent to those skilled in the ait. 

The dual diodes are arranged in pairs with the anodes of one of the dual 
diodes being coupled to the supply voltage +5V and the cathodes of the other dual 
diode being connected to the ou^ut of the corresponding driver circuit. 
Accordingly, the red diodes arc commonly driven by driver circuit 162. which is 
responsive to a signal received from the PT controller 98 on conductor 166. 
Similarly, the green diodes are commonly driven by driver circuit 164, which is 
responsive to a signal received from the PT controller 98 on conductor 168. 
Therefore, the PT controller 98 can selectively actuate the red diodes, the green 
diodes or both by generating the corresponding signals on conductors 166 and 
168. 

All of the conductors over which the PT controller conununicates with the 
card reader, i.e.. 146-156 and 166-168, are connected to a connector 170 as 
shown in FIGS. 6 and 7A. The player tracking module 44 then includes a cable 
172 that is connected between the connector 170 and the PT controller 98, as 
shown in FIG. 5. 

Although the preferred embodiment of the card reader is an optical card 
reader, the invention is not limited to such. The lighted bezel can be used in 
conjunction with any form of card reader such as a magnetic card reader, a bar 
code reader, etc. The method of providing visual feedback to the player herein 
described is a general method which can be used with a plurality of cards and card 
readers. 

5. Dismay 

Referring now to FIG. 8, a schematic for the display circuit 102 of the 
player tracking module 44 is shown. The circuit 102 includes a display controller 
174, which in the preferred embodiment is a part number HD64732S8P10 
manufactured by Hitachi of Tokyo, Japan. Coupled to the display controller 174 
is a memory 176 via bus 178. The memory 176, in the preferred embodiment, is a 
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32KB SRAM. The memoiy 176 stores the variables and parameters necessary for 
the controller 174 to conununicate with both the PT controller 98 and the display 
driver 186. The bus 178 includes the necessary address lines, data lines and 
control lines to interface in menooiy 176. 

In the preferred embodiment, the display 102 includes a vacuum 
fluorescent display (VFD) 1 84, which is oiianized as a 16 x 192 display matrix. 
Such displays are well-known in the art of digital electronics. The VFD 1 84 is 
driven by a driver circuit 186, which includes a plurality of individual drivers 
serially interconnected. In the prefened embodiment, these serial driven are part 
number UCN5818EPF-1, manufactured by Allegro Microsystems, Inc. of 
Worcester. Massachusetts. The driver circuit 186 is connected to the VFD 184 by 
bus 188, which includes 160 individual conduaors. The manner in which the 160 
bus lines are connected between the driver circuit 186 and the VFD 184 is known 
in the art, and is therefore not described in detail herein. 

The display controller 174 interfaces with the driver circuit 186 by a 
plurality of signal lines 190. These signal lines transmit the standard driver 
interface signals to the driver circuit 186. These signals include: a clock signal 
CLOCK, serial input data signal SDATA, a frame signal FRAME, a strobe signal 
STROBE, two output enable signals OEl/ and 0E2/, a column clock signal COL 
CLOCK, and a column output enable signal COL OE/. These signals have well 
known functions in the display art and are therefor not discussed in detail. The 
signal names having a " / " represent active low signals while all other signals are 
active hi^. The display controller 174 generates these signals in the required 
sequence in order to serially clock the refonnatted display data to the driver 
circuit One of ordinary skill in the art could program the display controller 176 
to generate these signals in wder to display the desired message on the VFD 184 
based on the foregoing description. 

The display 102 also includes a serial interface 192. The serial interface 
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192 is ttfee m^ms by wMch fthe PT coBtooHer 98 commumcffltes a pkyer traddng 
iK^ssag© to tfes display 102. Ira tlite pieffeirredl esKribodiinrteMit, Jfes seriffil iateirlFace 192 
' iracledes ttwo opJo-isolMor drcrnts: orae for the serial send data, the other for the 
serial Srmsmnissiosit data. The display controller 174 is coitimecsed to flhe serial 

5 interface 192 over a ttwo conductor serial bus 194, orae conductor for receiving 

serial data from the serial interface 192, the other for transmitting serial data 
thereto. A connector 196 is also coupled to the serial interface 192. The 
cominector 196 includes four terminals. Two of ^ connector terminals ase 
dedicated to receiving serial input data and the otlh^r two terminals are dedicated ' 

10 to transmitting serial data. A cable (not shown) couples the display 102 to the 

player tracking module 44 between connectors 196 (FIG. 8) and connector 115 

(Ha 5). 

6. Discrete Input Secoon 
The display 102 further includes a discrete input section 198. The discrete 
15 input section 198 is an interface between tSi^ discrete outputs of a gaming device 

and the display controller 174 much in the same way that tl^ discrete machine 
interface 72 allows the data communscation node to interface with a gaming 
device. Although in the preferred embodiment the discrote input section is 
unconnected to any discrote machine inputs, the discrote input section 198 allows 
20 the display 102 to operate as a stand-alone module for gaming devices in certain 

conifiguaations. The discrote input section provides discrete input signals from an 
external device to the display controller 174 over a bus 200. The discrote input 
section 198 includes opto-isolator dbccuits such as part number TLP620 
manisBfacturod by Toshiba Coirporation of Tokyo, Japan which provide single- 
25 ended input signals to the display controller 174. 

D. PERSONALITY BOARD 

Refemng now to FIG. 9, a personality board 202 is shown in schematic 
form. The personality board 202 uniquely identifies the gaming device on the 
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mettwoiifc. TBis psirsoiniallity board 202 iadicffites th© ttyps of gsiiimHig dtevicet e.g., slot 
mmscIhiiE© or vodbo polcer, mclQjd&ng ilbs smstisfactuin&ir, md pmvid^s a WMqime 
msicIhiiE}!© itettSficMfiOE ssismbsir ikm She host compusteir cm vise So ymqeely add^ss 
the gfflimmg device. The psKsoomlitty board 202 allows the devices to be iresdily 
s^moved md meisnstalled m the netwoiifc withoM my mmusi recoimOgwMioii by the 
opeiratoir, sisjch as n^setttiinig dip switches. 

The jpeirsoimality board 202 coiuples the data commumcation mode 42 to a 
gamiinig device. The persoaiality board 202 includes two connectors 204 and 206 
sind m identilfication drcMt 208. The connector 204 couples to the da^ 
commuiniicattioini node 42, as described further below. The connector 206 connects 
to the p^anlar gsming device. The components shown in FSG. 9 are mounted 
on a pdnted circuit board that is mounted inside a connector harness (not shown). 
The personality board allows the IDCN to be easily removed and reinstalled from 
the network with nmnimal eflTort 

The personality board uniquely identifies the machine by providing both a 
coniigTOSion nramber* which indicates the type of gaming device that is 
conin^ected to the connector 206 and a msque identification number, which is used 
by the system 10 to maintain records on the ratachine. The configuration number 
includes a six bit binary number which indicates the type of gaming device 
connected to the personality board 202. Each imachine type is assigned a unique 
conffiguration nmnber. This configuration number is encoded on lines CNFGO- 
CNFGS, which as^ connected to terminals 204Q-204V, respectively, of connector 
204. Each Mneinepresentsosie bit of the binary confi The 
individual lines ame either tied to a supply voltage to represent a binary one or to 
groiMd to represent a binary zero. The sm bit configuration number used in the 
ps^femed embodiment can encode up to 2^^ diffement combinatioHis and, therefore, 
different machine types. The configuration number for the embodiment shown in 
HG. 9 is ©qnal to 3CH. 
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The configuration lines CNFG0-CNFG5 arc coupled to the inputs of 
parallel to serial converter 86 (FIG. 3) through a connector (not shown). The 
terminals 204Q-204V of connector 204 have corresponding ternunals 85Q-8SV of 
connector 85, as indicated by corresponding lettered suffixes. This same lettering 
convention is used throughout. 

The configuration number is used by the DCN controller 46 as a means of 
interpreting the discrete input signals received from the machine through 
connector 206. Individual conductors coupled between connector 204 and 206 
are labeled to correspond to the machine type having a configuration number 
3CH. For a different machine type having a different configuration number, 
many of these conductors may have different functions. By providing a unique 
configuration number, the DCN controller can interpret the signals received on 
these lines accordingly. 

The personality board 202 also includes an identification circuit 208 which 
provides a unique machine identification number to the data conununication node 
42. The unique identification number is stored in a nonvolatile memory 210 and 
provided to a terminal 204N on conduaor ID. In the preferred embodiment, the 
nonvolatile memory 210 is a part number DS2224 manufactured by Dallas 
Semiconductor of Dallas, Texas. In the preferred embodiment, the nonvolatile 
memory 210 includes a 32 bit ROM having a factory-lasered unique serial 
number stored therein. This serial number, i.e., the machine identification 
number, can be read out of the memory 210 by the DCN controller 46 to uniquely 
identify the machine cormected thereto. The protocol for reading the 
identification number out of the memory 210, as is described in the data sheet for 
the part, is well known in tl^ art. 

The identification circuit 208 includes a number of discrete components. 
The memory 210 has a zener diode 212 coupled across the power and ground 
terminals of 213 and 215 thereof. The identification circuit 202 also includes a 
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dfiod© 2M couBpled bstwesini Ht^ jpower temniaial 213 md a dMa omput 
torariMiS 217. Tilts ckcmt 208 Iftarttlhsr Mudiades a second diode 216 coiujpSed 
ItettweeEi ^ dsM oiattpM (temiiinia!! 217 md ttteg gromd tteraiiiniaJls 215. A ir^istoir 
21 8 as kteirposed bstwesE (flu© dMSL om^mt ttermiHial 217 md xlts coMmcc terminal 
204N. TBte teraiiixial 204N is coiapled tto a comspoeding temMHual 74N of 
comectoir 74 (FIG. 4) by a buss 220 (FIG, 2). 

Htm dflscs^tte otattputs ifrom (the OBacMne, e.g., coimi in, coin out, etc., are also 
simpplned to the data commiamcatiom node 42 via bus 220. The bus 220 cosmects 
connector 74 of the data communication nodte 42 and the connector 204 of the 
lijefisonality board 202 such that teiminals Ihaving coinr^sponding lettemed suffixes 
are connecded. Fbr ejiample, temniiiBal 74C of connector 74 is connected to 
tenmiinial 204C of connector 20^4 by a individual conductor within bus 220. AM the 
other tenminals sm similarly connected by the bus 220. 

The networic interface 49 of the data coimmunication node 42 is also 
coupled to th^ pessonality board by a hm 222, as shown in FIG. 2. Bus 222 
includes four conductors which connects the four terminals of connector 51 with 
four corresponding terminals of connector 204, as indicated by tlte common 
letteir©d suMxes. It is over these four lines that the DCN controller 46 indirectly 
communicates with (the floor conttmller. 

Tlh^ serial machine interface 60 is also coupled to the personality board 202 
by a bus 224, as shown in HQ. 2, Hie bus 224 includes four conductors which 
couple four (tOTninals 62DD and 62EE of connector 62 with corsesponding 
terminals 204DD and 204EE» sespectively. It is over these four conductors tlM 
the DCN conttJToller 46 communicates ineconfiguration commands to the machine. 
The BCN controller transmits data through ttSi^ terminal 204DD, which is 
provided to (the nnachine on conductor MACHINE RX. The madme sesponds to 
the conffiguration command on the conductor MACHINE TX, The use of these 
two conductors will beconne more appas:ent in the description of the operation 
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Althoangh hmss 220, 222, 224 md 226 Mve bsesii descirilbsd ass sepsiraste 
b^ses, iLhe imdiivyusili coeducitors wiihimi these bi&ses could, aed si?^ ie the pieferiied 
embodimmeBt, combmed iMo si single buns ithM is connected betweeim {the data 
collection mode 42 and the personality board 202. To connect the data collection 
node 42 and the personality board 202 a connector (not shown) is sBOunted on iht 
data collection node 42 and a mating connector (not shown) is mominted on tl^ 
personality boaird 202, The two coniniectors are then mated together to connect the 
data collection node 42 to the personality board 202. The personality board is 
then coispled to the corresponding gamng device by a cable 225 (FIG-2). 

E. BONUS DISPLAY DRIVERS 

Referring now to FIGS. 10 and 1 1, two bonus display drivers are shown. 
The data connmunication node 42 is designed to support either of the display 
drivers. The data communication node 42 is coupled to the display driver of HG. 
10 through connector 228. An opto coupler 230 optically isolates the data 
communication node from a ttriac circuit 232 which includes a ttriac 234. One 
terminal of the triac 234 is connected to a terminal 236B of a connector 236. 
Another tesminal of the triac 234 is connected to a terminal 236C of connector 
236. A bonus display such as a light or sound generating sneans is coupled across 
terminals 236B and 236C so that the triac 234 could drive the external bonus 
display responsive to an actuation signal ifirom the data communication node 42. 

A second embodimientt of the display driver is shown in FIG. 1 1. In ttMs 
embodiment, the data comimunication node 42 is coupled to the driver circuit 
through connector 238. The driver circuit of HG. 11 1 includes a melay 240 
operatively coupled to a transistor 242. The relay 240 is a two-position relay 
which toggles between the two positions responsive to a current passing through 
transistor 242. The transistor 242 conducts a cusrent iresponsive to an actuation 
signal meceived on terminal 238B fsom the data communication node 42. 
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The display drivers are used by the data communicatioii node 42 to activate 
a di^lay on the gaming device which indicates that the machine is now in a 
bonus mode or condition. 

F. FLOOR CONTROLLER 

As shown in FIG. 1, the floor controller is directly connected to both the 
high speed network 38 and a plurality of gaming devices. The floor controller is 
responsible for monitoring the activity of each of the gaming devices connected 
thereto and reporting this activity to the database 32. In addition, the floor 
controller is responsible for transmitting a reconfiguration command to a selected 
one or more of the gaming devices during certain bonus conditions. These 
conditions will be described in detail in the operation section below. 

The floor controller is connected to the associated gaming devices by 
current loop networics. Because of the limitations of the current loop network, 
only a predetermined number of gaming devices can be supported on any one 
current loop network. In the preferred embodiment, each current loop network 
supports up to 64 gaming devices. In order for each floor controller to support 
more than this predetermined number of gaming devices, each floor controller is 
equipped with a conmiunication board 246» as shown in FIG. 12. The 
communication board 246 supports up to 16 separate current loop networks. The 
board is a standard size card that fits into one of the ISA card slots in the back of 
the floor controller. The board includes a male edge connector (not shown) which 
noates with a female back plane connector (not shown) in the floor controller. The 
back plane connector provides the floor controller CPU data, address, and control 
lines to the communication board 246 to enable the conmiunication board and the 
floOT controller CPU to communicate. 

The corrununication board 246 includes eight separate microcontrollers 
248A-248H. The microcontrollers communicate with the floor controller through 
ISA bus interface logic 247 over buses 249A and 249B. The microcontrollers are 
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shown in a daisy-chain connection in FIG. 12, but any other equivalent 
interconnection scheme can be used. The data received from the flom controUer 
microprocessor is passed between the niicrocontrollers from 248 A to 248H, as 
indicated by the arrows. Each microcontroller is responsible for passing the data 
along and determining whether the data includes a message for a machine 
connected to its corresponding current loop networks. 

Each microcontroller is responsible for two current loop netwoiks. Each 
microcontroller conununicates with its associated gaming devices via two 
corresponding current loop netwoiks. Two serial signal lines 251 connect each 
microcontroller to a current loop driver circuit 250. The driver circuit 250 
provides the necessary current drive to support the current loop networic. Each 
pair of serial signal lines 251 has a corresponding pair of current loop lines 253. 
The current loop driver circuit 250 can either be located on the conununication 
board as shown in FIG. 12 or on a separate printed circuit board (not shown). If 
located on a separate board, the current loop driver circuit 250 can be connected 
to the conununication board by a cable. 

In the preferred embodiment, the last microcontroller 248H is solely 
responsible for communicating with the floor controller microprocessor. All of 
the data received from the machines over the various current loop netwoiks are 
passed along to the microcontroller 248H by the associated microcontroller. The 
microcontrollw 248H analyses the data and determines whether the data needs to 
be conununicated to the floor controller. If not, the last microcontroller reccmls 
the conununication but does not forward the data to the floor controller. This 
helps ofT-load some of the floor controller communication processing to die 
communication board. 
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il. OPERATION 

The above-described system allows a casino in which the system is 
installed to ran pronnotions on any properly equipped gaming machines while 
simultaneously gathering player tracking and accounting data from all machines. 
The system provides the capability for the casino to select which of the plurality 
of machines are used in any given promotion. The system further allows any 
number of different promotions to operate simultaneously. 

Each promotion involves sending a reconfiguration command from the 
floor controller to a gaming device that has been selected to be part of a given 
promotion over the associated network. Upon receipt of the reconfiguration 
conunand, the gaming device reconfigures its payout schedule in accordance with 
the received reconfiguration command. As described above, reconfiguring a 
gaming device payout schedule, in the preferred embodiment, includes activating 
a bonus payout schedule that pays out bonus amounts in addition to the amount 
determined by the device payout table. 

A partial list of the promotions according to the invention include, but are 
not limited to: a multiple jackpot wherein the gaming device reconfigures its 
payout to be a multiple of its default payout schedule; a bonus jackpot wherein the 
gaining device reconfigures its payout schedule to payout an additional bonus 
amount when certain conditions are met; and a progressive jackpot wherein two 
<»* mote gaming devices are combined in a jnogressi ve jackpot having a 
progressive jackpot payout schedule. In addition to these, many other promotions 
arc possible by the above-described system for controlling and monitoring a 
plurality of gaming devices. 

The system 10 also allows for improved player tracking. As with standard 
player tracking, the above-described system monitors and reports how many coins 
are played by each player. The system 10, however, also includes the ability to 
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sm>irdl Ihtow long esA pteyeir spsmds at each macMme md the lumter of coins 
won, games played, aad liaad jackpote woia by eacSi player. All this information 
is stoired on tite database, which can be later analyzed for Mure targeted diiiect 
mailing campaigns. The player tracking according to tl^ invention also altows 
5 the casino to schedule buses and other groups and measure their profitability. The 

system also allows for cashless play as well as advanced accounting and security 
features. 

Ancrther feature of the above-described system is jackpot announceBBents. 
The jackpot announcement feature displays a message on a reader board or 

10 display located in the casino which announces a jackpot as soon as a jackpot is 

won, i.e., as soon as the reels stop spinning. The floor controller generates the 
jackpot announcement once a DCN connected thereto indicates a jackpot is won. 
An e;iaii^le of such a message might be: "Now paying on machine 1342, a 
jackpot of S3C0." Withpriorart data collection systems, the amount of the 

15 jackpot is only known after the payment is imade. Even then the system must 

account for partial pays, hopper empty, etc. 

An advantage of the current system over prior art systems is the ability to 
implement better tournament systems. In a slot tournament, players pay a fee to 
play. All play during the session is free. The players accumulate credits instead 

20 of cash. The peirson with the miostt credits at the end of the tournament wins. 

Games are usually cnanually altered to provide payouts of 200 to 300% to OBake 
the games mors Ifun. The gam^es are altered mianually by replacing the read only 
memtory (ROM) m the gaming devices. 

One exciting aspect of tournament play is to see who is ahead. No current 

25 system can display this infonmtion in real time. This is because current systems 

can only n^easure winnings as they are added to the credit meter or paid from the 
hopper (sontre casinos use toumam^ent tokens instead). Since credits are usually 
added at a rate of lO per second, a 1,000 credit win can take 100 seconds to 
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register. Casinos attempting to create display boaids showing who is ahead are 
firustrated by the lag time. Thejackpot announcement ofthe invention allows 
casinos to display the player widi the most credits by comparing the number of 
credits for each player. This comparison and display is performed real time as 
each transaction is completed. 

In order to implement each of these features, the various computers and 
microcontrollers each execute software or firmware. This software and firmware 
routines are described below. These routines are described witf» reference to 
accompanying flow charts. These flow charts would enable one of ordinary skill 
in the art of computer programming to write a corresponding computer program 
which the computer or microcontroller could execute. 

A. DATA COMMUNICATION NODE 
1. Power Up Procedure 

Referring now to FIG. 13, a power up procedure 252 for the data 
communication node is shown. This procedure is executed by the DCN controller 
46 when initially powered up. The first step of Uie procedure is to validate the 
RAM to ensure that it is not corrupted and to set up all the DCN hardware. 
Validating the RAM involves writing known patterns of Is and Os to the DCN 
RAM. This RAM can either be internal to tiie DCN controller 42 or external as 
shown in FIG. 2. Setting up the DCN hardware includes initializing timere and 
interrupts. 

Next the DCN contix>ller checks U»e RAM in step 255 by reading tiie 
pattern of Is and Os back out of die RAM to ensure that the RAM is fiilly 
ftinctional. If the RAM turns out to be defective the DCN controller goes into an 
mdless loop in 256. 
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2. Reai»ng Unique iDErmncAxiON number 
If the RAM is fiilly functional, the DCN then reads the unique 
identification number from the personality board. As described above, this 
unique identification number is stored in a nonvolatile memory 210 on die 
personality board. Reading the unique ID number out of the nonvolatile memory 
involves following the memory manufacturer's interface protocol as specified in 
the nonvolatile memory data sheet. The unique identification number provides a 
means for uniquely identifying the gaming device. 

After the unique ID has been read from the personality board, the DCN 
processes the discrete machine inputs in step 260. This step will be described in 
further detail in Subsection 3, Monitoring Gaming Device Discrete Input 
below. After the discrete inputs have been processed in step 260, the DCN 
processes the machine serial interface in step 262. This step is described further 
below in Subsection 4, Processing Gaming Device Serial Interface. Next, 
the DCN processes the network interface, i.e., the interface between the DCN and 
the floor controller connected thereto. The process network interface step 264 is 
described further below in Subsection 5, Processing Network Interface. 
Finally, the DCN processes the player tracking interface in step 266. This step is 
described below in Subsection 6, Processing Card Insertion. At the 
completion of step 266 the DCN loops back to step 260 and continuously, 
sequentially executes steps 260-266. 

3. Monttchung Gaming Device Discrete Input 
Referring now to FIG. 14, the DCN step of monitoring the gaming device 
discrete inputs 260 will now be described. The DCN first reads the discrete 
inputs on input lines 76 in step 267. One particular set of discrete inputs is shown 
in FIGS. 4 and 9 for a particular gaming device. The actual discr^ inputs 
present will depend on the madiine type, as indicated by the configuration 
number, which is also read by the DCN controllo- 46. Most gaming devices 
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provide m lesss mms olT ttSis folSowiag disareue rnpyts: coias in, coims oai, coins to 
drop, gasmss played, s^wimt paid jscCqjois, sloa door, drop door, pogpessive 
jfflclqpotts, md hM vaHdators. TSi© sys«em snippom all off these discireie impHts as 
well as {^tm. 

The IDCN Iseeps teack of the macMne activity by imaintaining several meters 
in iBteimoiry. Eaclh jngter, in the prefesinsd embodiisKnt, in^^^ 
Moreover, to improve the reliability of the system, the IDCN maintains redundant 
backup copies of these meters with an order to replace the original msteirs in the 
©vent thaJ tlie origkals are coxrapted. In step 268, the BCN increments the metere 
as required based on fihs discrete aapatts. The meters are maintained evoi in the 
event that tSi® BCN is disconnected l&om the floor controOer. Once tfcs BCN is 
reconnected to the icor controller, ail the activity level information is then 
available. Step 268 will bs discussed ftirther below. 

Next, the BCN processes the drop door signal in step 270. The drop door 
signal DROP BOOR indicates that the drop door on the macMne has been 
opened. This is an important ©vent and is therefore processed sepasraaely. 

Hn step 272, the BCN validates the mneter valanes to determine whether the 
values Stored in the meters are valid. The BCN checks whether the meter values 
are valid in step 274. In the prefeired eimbodiment, a check sum is maintained for 
each raieter value. Thus, the BCN in step 274 checks to see whether the check 
sum is correct based on the current meter value. If the meter values are okay, the 
discrete input monitoring step 260 is complete. If the meter values are not valid, 
the BCN replaces nhe nsieter values with the nedundant back copy of the meter 
values in step 278, and then the step 260 is complete. 

Refessing now to FIG. 15, increment meter step 268 is shown in further 
detail. The sequence shown in HG. 15 is repeated for each raster value that has 
changed. Tte first step is to adjust the meter value based on the discrete inputs 
and to calculate the associated check sum. Nejit, the BCN detenmines whether the 
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particular meter has an active associated countdown count in step 282. Some 
games or promotional activities require the player to reach a certain level of 
activity in order to be eligible for certain bonus points. These countdown counts 
are used to determine whether the player has achieved this level of activity. For 
example^ the player nruiy be required to play a certain number of coins before 
being awarded any points. If the countdown count is active, the DCN adjusts the 
current players count down values in step 284 based on the corresponding 
adjustment of the associated meter. 

In step 286, the £>CN sets the current message to the count down mess^e. 
The count down message indicates to the player when he or she will be eligible 
for the bonus points. Finally, in step 288 the DCN sets the current bezel color and 
rate to a count down color and rate. This color and rate information is 
subsequently transmitted to the player tracking node for processing, as described 
further below. The countdown color indicates the bezel color and the count down 
rate indicates that flashing rate of the bezel color displayed during the count down 
message. 

4. Processing Gaming Device Serial Interface 
Referring now to FIG. 16, a process 262 for processing the gaming device 
serial interface is shown. Tte serial machine interface 60, as shown in FIG. 2, 
allows the DCN controUer 46 to conmiunicate with the gaming device through the 
personality board. This serial machine interface allows the DCN controller 46 to 
transmit reconfiguration commands to the gaming device in order to reconfigure 
the payout schedule of the machine in accordance with the reconfiguration 
conunand. In addition, the serial machine interface provides an additional means 
for determining the activity level of the gaming device. Instead of reading the 
discrete machine inputs, the DCN controller 46 can transmit a status request 
command to the machine over the serial interface and the machine can respond 
back with the requested status information. 



96113262 



PCr/DS9S/11610 



42 

Any communicatioii pn^ocol can be used to implement this communication 
path over the serial machine interface, as is known in the ait. An example of one 
such protocol uses a data packet including a command code, a message sequence 
number, a CRC, and a variable length message. In the preferred embodunent, 
either the DCN controller 46 or the machine can initiate conununications over the 
serial machine interface. However, if the machine detects that the DCN is trying 
to send a message to the machine, the machine must abort its message and attempt 
to resend the message at a later time. 

The preferred embodiment of the system supports numy different 
reconfiguration commands. A partial list of the reconfiguration commands is 
given below in Table 1. These reconfiguration commands are sent from the DCN 
controller 46 to the machine over the serial machine interface wherein the 
machine reconfigures its payout schedule in accordance with the particular 
reconfiguration command. The reconfiguration commands do not originate with 
the DCN, instead the reconfiguration commands originate ftom the floor 
controller and are transmitted to a particular machine over the associated cuirent 
loop networic or the command can originate at one of the other computers on the 
high speed networic. The DCN is simply responsible for forwarding the 
reconfiguration command onto the gaming device on receipt of the 
reconfiguration command over the associated cuirent loop network coupled 
between the flo(»^ controller and the DCN. 



Table 1 - Examples of Reconfiguration Conunands 

1 . Bonus Pay From Hopper (Coin Format) 

2. Bonus Pay to C^t Meter (Coin Format) 

3. Bonus Pay from Hopper (Dollar Format) 

4. Bonus Pay To Credit Meter (Dollar Format) 

5. Add Non-cash outable credits to Game 

6. Begin Double Jadcpot Time 

7. Stop Double Jackpot Time 
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The actual process of processing the machine serial interface begins in step 
292 wherein the DCN polls the machine to determine its level of activity. This 
polling step includes sending a status message from the E>CN to the machine over 
the serial machine interface. In response, the machine will send a packet of status 
information indicating the current amount of activity on the machine. The status 
information included in the response will depend on the type of machine that the 
DCN is conmiunication with. 

The data communication node 42, in step 294, waits for a reply to the status 
request. If a reply is received, the DCN indicates that the machine is "on line" in 
step 296 and processes the machine reply in 298. The step of processing the 
machine reply includes updating the meter values, as done when processing the 
discrete inputs. After the machine reply has been processed, the process 262 is 
complete. 

If the DCN does not receive a reply from the machine in step 294, the DCN 

indicates that the machine is "off line". The DCN will wait for a predetermined 

amount of time before deciding that the reply is not received. In the preferred 

embodiment, this predetermined period is approximately 110 milliseconds. 

p 

5. Processing NETWORK INTERFACE 
Another step in the DCN power up procedure 252 is the step of processing 
the networic interface 264. This step is described with reference to FIGS. 17-19. 
The network interface refers to tl^ current loop that connects the particular DCN 
with the associated floor controller. The following description assumes that the 
DCN has received a valid n^ssage from the associated floor controller. Because 
thm are multiple 

DCNs coimected to any one current loop, the floor controller must include some 
means for addressing a particular nuurhine. 

Although each machine includes a unique identification number which 
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could be used as the actual address for each DCN on the current loop, it is 
unnecessary to use the unique identification as the actual address because there 
are only a limited nundwr of DC34s connected to each current loop. Accordingly, 
in the preferred embodiment of the invention, the floor controller uses a shorthand 
token representation of the DCN's unique identification number to address the 
DCN. In the i»efened embodiment, a single byte address is used to address a 
DCN on any given current loop. This one-byte address allows up to 256 DCNs to 
be supported on any given current loop network. In the preferred embodiment, 
however, only 64 such DCNs are connected to a single current loop and therefore 
the single byte address is more dian adequate. The single byte address 
substantially reduces the amount of traffic on the current loop network by 
reducing the number of bytes firom four in the unique identification number to one 
for the shorthand token representation. 

The floor controller is responsible for generating the unique single byte 
address for each data communication node on a given current loop network. The 
process of assigning unique single byte addresses to the DCNs is described below 
in Section C. 

Once all the DCNs have been assigned a unique address, the DCN can 
begin monitoring the current loop networic for messages addressed to it. If the 
DCN detects a message addressed to it, the DCN executes step 264. The DCN 
first checks to see whether the message is valid in step 304. This check is done by 
computing the CRC value of the message and comparing it to the CRC included 
with the message. If the two CRCs match, the message is valid and the DCN 
processes the network message in step 306. Processing the network message is 
described further below with reference to HGS. 18 and 19. Once the message has 
been processed, the DCN sends a reply back to the floor controller over the 
current loop network in step 308. The actual substance of the reply wiU depend 
on the message received in step 306. If the message is invalid, the DCN does not 
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reply* 

Referring now to FIG. 18» the fiist step of processing the network message 
is to determine what type of message was sent from the floor controller in step 
312. There are three basic types of messages that the floor controller sends to the 
DCN. The first is a request for data from the DCN. If this type of message is 
detected the DCN builds the data requested and transmits the data in a reply 
message. The main use of this message type is to gather status and meter 
information from the DCN. 

Another type of message is one including configuration data for the DCN. 
This message allows the floor controller to implicitly set the DCN*s memory to a 
fixed value. This message is used to override the DCN's internal variables, e.g., 
to get a DCN out of a lock-up condition, or to download new jfirmware to the 
DCN for execution. On receiving this type of message, the DCN simply 
overwrites its memory with the configuration data included in the configuration 
message in step 316. The DCN then builds an appropriate acknowledgment and 
transmits this acknowledgment message to the floor controller in step 320. 

The other type of message is one sent in response to a DCN request. The 
DCN processes this data in step 318, which is described further in FIG. 19. If the 
message includes either the configuration data or the data in response to a DCN 
request, the DCN builds an acknowledge message in step 320 and transmits this 
message to the floor controller. 

The step of processing a floor controller message sent in response to a DCN 
request will now be described with reference to FIG. 19. The first step of 
processing this type of message is for the DCN to determine what type of data is 
included in the message. Once again there are three types of data that can be 
included in this message type: a reconfiguration command, card data, or other 
minor data. The DCN makes this determination in step 324 by analyzing one of 
the bytes in the data pack^ of the message. This byte will be referred to herein as 
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the command byte. If die command byte indicates that the message contains 
reconfiguration data, i.e., die command byte equals a leccmfiguradon command, 
the DCN stores the reconfiguration data in a predefined data structure in memory. 
Listed below in Table 2 is an example of a data structure for storing the 
reconfiguration data. 

Table 2 ~ Reconfiguration Data Structure 

1. Bonus Type 

2. Mystery Jackpot Data: 

A. Number of coins to award 

B. Number of seconds to award 

C. Pay award to 

3. Bonus Time Data 

A. Jackpot Multiplier 

B. Jackpot Payout Limitations 

C. Nurobn- of Seconds to Keep Bonus Time Active 

D. Minimum Activity Level 

The bonus type field of the data structure indicates the type of bonus state 
the machine is to be placed in. Examples of potential bonus modes include 
progressive/nonprogressive, multiple jackpot, or my steiy jackpot. If the mystery 
jackpot is indicated, die mystciy jackpot data included in die structure specifies 
die conditions under which die mystery jackpot is paid out. The mystery jackpot 
can be set to payout, e.g., after a certain number of coins in. handle pulls, which is 
specified by subfields of the mystery jaclqiot data. 

The bonus time jackpot is a pn>nK)tion wherein the machine pays out more 
dian diat dictated by its default payout schedule. In one embodiment of die bonus 
time promotion, the payout schedule of die machine can be modified to be a 
multiple of its default to payout schedule, as specified in subfield (A) of die bonus 
time data. This promotion can be used to encourage gaming activity during off- 
peak hours, e.g., midnight to 4 a.m. on weeknights. Alternatively, the bonus time 
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promotion can be activated on a random basis. The timing of the multiple jackpot 
is specified by the casino on one of the computers connected to the network. The 
bonus time data also specifies the conditions under which the player becomes 
eligible for the bonus tin^ jackpot. The subfield (B) of the bonus time data 
specifies whether the player is eligible for the bonus time data only if the player is 
playing the maximum coin in the machine. Subfield (C) limits the bonus time 
promotion to a predetermined number of seconds. This field limits the bonus 
time promotion to a predetermined number of seconds; if the player does not hit a 
jackpot within diis specified time period, the bonus time promotion concludes. 
The minimum activity level can also be specified in subfield (D). This field can 
be used to specify the minimum activity level required by the player in order to be 
eligible for the bonus time jackpot. For example, the player can be required to 
play at least 20 coins over the last three minutes in order to be eligible for the 
bonus time jackpot. An indicator Itght on the player's machine can be used to 
indicate when the player reaches the minimum activity level and thereby becomes 
eligible for the bonus time jackpot. 

In another embodiment of the bonus time promotion, a bonus amount is 
awarded in additicm to the payout according to the default of the payout schedule 
of the machine. The amount of the bonus jackpot is specified in subfield (E) of 
the bonus time data. For example, this bonus time promotion might include five 
bonus amounts of $10, $25, $50, $100 and $500, which is specified by subfield 
(E). When a player hits a particular jackpot, whichever bonus amount is specified 
by the bonus amount subfield this amount is automatically paid out in addition to 
the payout amount determined by the machine's default payout schedule. This 
bonus time promotion can also be used in combination with subfields (C) and (D) 
to specify the conditions under which the player is eligible for this bonus time 
jackpot award. 

After the DCN has stored the reconfiguration data in step 326, the DCN 
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will then send die impropriate reconfiguration command to the machine over the 
serial machine interface in step 328. The machine, responsive to the received 
reconfiguration command, reconfigures its payout schedule in accordance with 
the received reconfiguration command. For example, if the reccmfiguration 
command specifies a multiple jackpot condition, die machine will reconfigure its 
payout to be a multiple of its default payout schedule. The machine will 
reconfigure its payout schedule in a similar manner for the other bonus types. 

The other type of data that can be included in a response from a DCN 
request is card data or player tracking data. This data is sent to the DCN in 
response to a status message from the DCN to the floor controller wherein die 
status message indicates diat a player card has been inserted. Included in this 
message is die card ID number detected by die card reader. In response to diis 
status message die floor controller will transmit a card insertion message to die 
DCN. The card insertion message includes information associated widi the 
particular player ID number. An exemplary card insertion message data packet is 
listed below in Table 3. 

TABLE 3 ~ Card Insertion Message Data Packet 

1. Card Identification Number 

2. Player First Name 

3. Player Last Name 

4. Current Point Balance 

5. Casino Code 

Upon receipt of die card insertion message, die DCN stores die player's 
name and points in order for this information to be displayed on the VFD display 
associated widi die player tracking node. Then, a DCN sets die current message 
to a data received message in step 334. Finally, a DCN sets die current bezel 
color and bezel rate to a data received bezel color and bezel rate in step 336. The 
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bezel color specifies the bezel color to be displayed by the card reader and the 
bezel rate specifies the flashing rate of the card reader LEDs. This bezel 
infonnation is subsequently transmitted to the player tracking node for processing 
thereby. 

The final data type that can be included in the message sent from the floor 
controller in response to a DCN request is generically classified as other minor 
data. This data includes general system or DCN specific information such as 
display infomiation. 

6. Processing Player Tracking Interface 

The next step in the DCN process is processing of the player tracking 
interface 266. The DCN maintains a variable that indicates what message is to be 
sent to the player tracking node. This variable is referred to as the current 
message variable. Before transmitting a message to the player tracking node, the 
DCN first checks this variable to see which of a plurality of messages should be 
sent to the player tracking node. 

The process 266 begins in 340 by sending the current message to the player 
tracking node that is specified by the current message variable. In addition to the 
current message, the DCN sends the bezel color and bezel rate information to the 
player tracking node. The bezel color and bezel rate information could have been 
specified by the floor controller or by the DCN itself 

Next, the DCN determines the card status in step 342. If there is no card 
inserted in the card reader, the DCN sets the current message variable to an attract 
message. This message specifies that the player tracking node is to display a 
message which will attract players to Uie machine. Similarly, the DCN sets the 
current bezel color and bezel rate to an attract bezel color and rate in step 346. 
This attract color and rate is part of the attract message that will be sent to the 
playa tracking node when the current message is sent 

If the DCN determines that a good card has been inserted in the card reader. 
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the DCN processes the valid card in step 350. This step is described fuither 
below with reference to FIG. 21. 

If, however, the card status indicates that a bad card has been inserted, i.e., 
an invalid card number, the DCN sets the current message variable to specify a 
card error message in 352 arid the DCN sets the cuirent bezel color and bezel rate 
to a card error color and rate in 354. This card error information is included with 
the card error message that is sent to the player tracking node when the current 
message is sent. 

7. Processing Card Insertion 

Referring now to FIG. 21, the process 350 for processing a valid card 
insertion is shown. The first step that the DCN executes is to determine whether 
the card data corresponding to the valid card has been received from the floor 
controller in step 356. If not. the DCN builds a networic request message for the 
player name and points associated with the card ID number in step 358. Next, the 
DCN sets the current message variable to specify a card inserted message is to be 
transmitted in step 360. Finally, the DCN sets the current bezel color and rate to a 
card inserted color and rate, which indicates to the player that the system is still 
processing the card number. This information is sent to the player tracking node 
when the current message is sent. 

If the card data has been received from the floor controller, the DCN then 
determines in step 366 whether player tracking has started for the particular 
player. If player tracking has not yet started, the DCN sets the current message 
variable to the data received message in step 368 and sets the current bezel color 
and rate to data received color and rate in step 370. If player tracking has started, 
the DCN processes the player tracking in step 372, as described with reference to 
FIG. 22. 

Processing player tracking 372 begins with the step of determining whether 
the player has received new points in 374. These points can be considered 
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roughly as the equivalent of "frequent flyer miles" used by airlines. These points 
allow the system to run promotionals whereby individuals are given points or 
credit associated with their card that can be redeemed toward the purchase of 
goods or services offered by the casino. Typically these points are redeemed at a 
redemption counter in the casino for meals or clothing, for example. The points, 
therefore, are an additional inducement to encourage play. 

The player tracking system of the invention allows the casino to determine 
how and when the player is issued points. The casino can specify the type and 
number of coins that must be played before a player is awarded a given number of 
points. The system uses this specified information to inform the player of his or 
her progress towards receiving additional points. The system encourages play by 
informing the player of how many additional coins must be played before 
receiving additional points. For example, a player who is only one coin away 
from receiving points, but who desires to stop playing, may decide to play "one 
last coin" in order to receive the points. The system informs the player by 
displaying a message on the vacuum florescent display indicating how many 
coins the player is away from receiving additional points. 

Referring now to FIG. 22, player tracking 372 begins with the step of 
determining whether the player has received new points in 374. If no new points 
have been received, the DCN sets the current message variable to specify a 
countdown message in step 376 and sets the current bezel color and bezel rate to a 
countdown bezel color and rate in step 378. 

The countdown bezel color and rate indicates the player's progress towards being 
awarded additional points* 

If new points have been received, such as where the player has played a 
given number of coins» the DCN sets the current message variable to a points won 
message in step 382 and sets the current bezel 

color and rate to a points won color and rate in step 384. The points won message 
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mffomms tthe jplayer of iHts atsMnbsir of pomts woe. 

Tb^ above-dlesarnSjsd fiirfficMng process provides a mttgans for providmg 
■ visBJSil feedback to the pkyer iiasertsng ftfee card into (the card ireader. By 
modifyiflug the IbeEel color md bezel rate, the data commixmcatsoB aode provides 
immediMe feedback to ahe player comcenning the proper insestHOKH of the card. If 
the player imserts the card properly nitito the card reader so that the card reader 
semises a valid oiser idemittiScffltiosii auimber, the card reader provides positive visual 
feedback to the laser by illimiimating the bezel. Omi the other haad, if the user 
improperiy ieseiris the card so that the card reader casmot read the oiser 
ideBtilficatioxii nxiamber. tite card reader cm provide negative visual feedback to the 
player by illumiimatisiig the bez©! with a different color aod/or fflashimg rate. M the 
prefeinred embodimgiat, this positive visual feedback includes flashing the gireen 
LEIDs to produce a iflasMng gx^en signal around the card ireader opening. Tl^ 
negative visual feedback includes flashing the red LHDs. A third combination 
color is used during the processing of the player tracking inforaiation. This 
process provides imnediate feedback to the player concerning the insertion of the 
card in the card reader. 

B. PLAYER TRAOONG MODULE 

The systemni described above allows for improved player ttmcking by 
recording each and every KiiBacMne transaction including: time of play, machine 
number, duration of play, coins nn, coins out, hand paid jackpms and games 
played. The player (tracking is conducted over the same network as the 
accounting data is ejiitracted. This allows the invention to provide bonusing to 
certain individual playejs as well as during certain tames. As with standawl player 
JracMng, the above-described system nM>nitors and reports how many coins arc 
played by each player. The system according to the invention, however, also 
includes the ability to n©cord how long each player spends at each machine and 
the nunaber of coins won, gaiMs played, and hand jadkpots won by each player. 
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The system is able to record all this information because the it opiates on a 
transaction by transaction basis. Each transaction, whether it be a coin in, a 
handle pull, etc., is recorded by the system. Other prior art systems simply 
compile the player tracking information at the completion of play. 

All the transaction information is stored on the database, which can be later 
analyzed for future targeted direct mailing campaigns. The player tracldng 
according to the invention allows the casino to schedule buses and other groups 
and measure their profitability. Because the system records each transaction, the 
casino can reconfigure their casinos to better match the tastes and demands of 
their customers. 

The improved player tracking according to the invention also allows the 
casino to calculate theoretical wins exactly because the system always includes 
the most current information. The operation of the player tracking procedure is 
described below. 

1 . POWER Up Procedure 

The operation of the player tracking module will now be described with 
reference to FIG. 23 where the powerup process 400 for the player tracking node 
is shown. As in the data conmiunication node, the player tracking node first 
validates tte RAM and sets up its associated hardware in step 402. Next, the 
player tracking node tests the RAM in step 404 to determine whether the RAM is 
functioning properly. If not, the player tracking node, i.e., player tracking 
controller, terminates its program in an error condition in step 406. If the player 
tracking RAM is fully functional, the player tracking node sequentially executes 
steps 408-414. In step 408 the player tracking controller processes the DCN 
interface between the player tracking controller and the £>CN controller. In step 
410 the player tracking controller updates the player tracking display. In step 41 2 
the player tracking controller updates the bezel. Fmally, the player tracking 
controller processes the card reader in step 414. Each of these steps will now be 
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described fiiither below. 

2. Processing DCN Interface 

Refeiring now to FIG. 24, the steps for processing the DCN interface arc 
shown. First, the player tracking controller checks for a new message received 
from the DCN in step 416. If a new message has been received, the player 
tracking controller overwrites its current message buffer with the new message 
and updates the bezel color and rate values with those contained in the new 
current message. Then, the player tracking controller builds a card status reply 
message in step 420. The card status message indicates whether a card has been 
inserted and if so whether the card was a good card or a bad caid, i.e., the card 
was read properly by the card reader. If a valid card, the card status reply 
message also includes the identification number encoded on the card. This step 
might also involve transposing the number encoded on the card depending on the 
orientation in which the card was inserted into the card reader. This card status 
reply message in then sent to the DCN in step 422. 

3. Processing Display Update 

The process of updating the player tracking display is shown in HG. 25 at 
410. This process begins with the player tracking controller scanning the display 
message for display attribute information. Examples of such display attribute 
information is given below in Table 4. Each display attribute specifies a different 
graphic mode for the player tracking display. 



TABLE 4 - Display Attribute Information 

1. Flash Rate 

2. Center Display 

3. Set Display Intensity 

4. Use Small Lower Font 

5. Use Small Upper Font 

6. Use Normal Large Font 

7. Set Pause Time 
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8. 


Set Scroll Speed 


9. 


Center and Melt 


10. 


Center and Scroll Down 


11. 


Center and Scroll Up 


12. 


SooU Down and Stop 


13. 


Scroll UP and Stop 


14. 


Scroll Left and Stop and End of Message 


15. 


Scroll Down 


16. 


Scroll Up 


17. 


Scroll Right 


18. 


Scroll Left 


19. 


Reverse Video 


20. 


Nomud 



The player tracking controller then determines whether any such attribute 
information is found in the display message. If so, the player tracking controller 
sets up the display driver to incorporate the graphics mode specified by tl^ 
attribute information. The player tracking controller then strips out any display 
attribute information from the display message in step 432 because the display 
attribute information is embedded in the display n^ssage. The remaining data in 
the display message is the actual text to be displayed by the player tracking 
display, e.g., the player's name. The player tracking controller then sends this 
text to the display in step 434, which is then displayed by the player tracking 
display* 

4. Processing Bezel Update 
The player tracking node is also responsible for updating the bezel, bc^ in 
terms of its color and flashing rate. This process 412 is shown in FIG. 26. The 
first step in processing the bezel update is to determine to bezel color as specified 
by the DCN and then drive the appropriate LEDs in the card reader. As described 
above, the preferred embodiment of the card reader includes dual diodes having 
two primary colored diodes that 

can be driven sqiarately or in combination to produce three different colors. 
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Next, the process detennines the bezel rate as specified by the DCN. In a 
first case, the bezel rate is zero or off and thus the player tracking controller turns 
the LEDs off in step 442 in this case. If the bezel rate specifies a flashing rate, the 
player tracking controller flashes the bezel at the s^propriate bezel rate in step 

5 442. Flashing the bezel involves turning the LEDs on and off at the specified 

rate. This can be accomplished by a timer interrupt or a timing loop executed by 
the player tracking controller. The final option is that the rate can be infinite or 
effectively a solid bezel color. In this case, the player tracking controller simply 
leaves the card reader LEE>s on in step 446. This completes the processing bezel 

10 update process 412. 

5. Prcx:essing Card Reader 
The next process step for the player tracking node is to process the card 
reader. This process 414 is shown in FIG. 27. The first step is for the player 
tracking controller to determine the card status in 450. In the preferred 

1 5 en>bodin)ent, the card status is determined by comparing the checksum of the 

card, as read off the card by the card reader, to a computed checksum of the data 
read off the card. Other noethods of determining card status can be used as well 
depending on the type of card reader employed. 

If the player tracking controller determines that a valid card was inserted in 

20 the card reader, the player tracking controller sets a card status variable equal to 

good card. This card status is then subsequently transmitted to the DCN 
controller. Then, the player tracking controller sets a card ID variable equal to the 
identification number read by the card reader in step 454. The card status and the 
card ID provide the DCN with sufficient information to instigate the player 

25 tracking. 

If, on the other hand, the card reader indicates that the card was read 
improperly or that the card is an invalid card for the card reader, the player 
tracking controller sets the card status variable to bad card in step 458 and the 
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card ID variable is cleaied in step 460. If neither a valid or invalid card condition 
was detected in 450, the player tracking controller sets the card status variable to 
no card in step 462 and clears out the card ID in 460. 

C. FLOOR CONTROLLER 

1 . Power Up Procedure 

Referring now to FIGS. 28-32, the process 464 operable on the floor 
controller will now be described. The process 464 is shown in FIGS. 28-32 in 
flow chart forms. These flow charts would enable one of ordinary skill in the art 
to implement the process in computer software using an appropriate computer 
programming language. 

The floor controller process 464 begins at step 466 by opening the database 
tables in the file server. As described above, the file server includes a 
commercially-available database program which stores the nmchine activity 
information as well as player tracking information and associated system 
characteristic parameters. This step 466 can also include fetching some or all of 
these system characteristics in order to trigger certain events such as bonus 
jackpots, as described below. 

In step 468, the floor controller terminates any active player tracking 
sessions in the database. Because player tracking may have been in progress 
when the floor controller became inoperable, when the floor controller powers up 
or becomes operable, there may be player tracking sessions initially active. In 
this step, the floor controller terminates any such active player tracking sessions 
in order to place the database in an initial state. 

Another step that the floor controller executes after becoming operable is to 
place an initial machine search message in an output message queue 470. This 
search message is used by the floor controller to determine which machines are 
connected to the floor controller This output ntessage is subsequently 
transmitted to all of the machines coupled to the floor controller using a global 
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message format, as described below with reference to FIG. 31 . In the prefened 
embodiment of the invention, the message handling is through the use of message 
queues. Furthermore, the preferred embodiment is both an output queue for 
outgoing messa^s from the floor controller to the machines and an input ntessage 
queue for messages coming from the machines to the floor controller. Queues are 
well-known data structures in the art of computer science and are therefore not 
further discussed herein. Alternatively, the message-handling could be done 
without the use of the queues. In such an embodiment the outgoing messages 
would be sent immediately rather than being queued, and any incoming messages 
would be processed inunediately. 

The bulk of the woik performed by the file server process 464 is performed 
in message processing step 472. In this step, the floor controller processes all 
messages sent to or received from the machines connected thereto. This step will 
be described further below with references to FIGS. 29 through 31. 

The process 464 also includes a system monitoring step 474. This system 
monitoring step 474 administers certain system-wide events. These system-wide 
events include the counting-related events and bonusing events. The floor 
controller continuously checks to see whether any of these events have been 
triggered. If any event has been triggered, such as a bonusing event, the floor 
controller takes the appropriate action to handle the event. The event may be 
trigga«d by the time and day or 

by user intervention or other event. The system monitoring step 474 will be 
desoibed further below with reference to FIGS. 32 and 33. 

The final step in [nocess 464 is for the floor controller to check for a 
termination condition in step 476. In the preferred embodiment, the floor 
controller checks to determine whether an ESCape key as pressed. If an ESC key 
was pressed, the floor controller terminates the process 464. If no ESC key was 
pressed, the floor controller loops back to step 472 wherein the message- 
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processing step and the system nionitoring step are lepeated. The floor controller 
continues in the loop 472-476 until the termination condition is sensed. 
2. Message Processing 

As described above, the floor controller acts as a gateway between the 
machines connected thereto and the file server, as shown in FIG. 1 . The floor 
controller is responsible for forwarding the machine activity received from the 
various machines to the database. The floor controller accomplishes this 
communication through the use of messages. The message processing step 472 is 
shown in more detail in FIG. 29. 

The first step in processing the messages is for the floor controller to send 
any messages that are queued-up in the output message queue to the appropriate 
data conununication node in step 480. As described above, the output message 
queue is a simple data structure that is used to store any pending messages. 
Included in the message is a destination address by which the floor controller can 
determine which of the plurality of data conununication nodes to send the 
message to. Next the floor controller receives any incoming messages from the 
data communication nodes coupled to the floor controller in step 482. Once an 
incoming message has been received, the floor controller parses through the 
message data included in the incoming message in steps 484 through 486. In the 
preferred embodiment, the floor controller parses through the message data one 
byte at a time. Thus, in step 484 the floor controller reads the next byte in the 
incoming message, and in step 486 the floor controller checks to see whether this 
is the last byte in the message. In the preferred embodiment, the message 
includes a message length field which indicates the number of data bytes included 
in the message. In this case, a floor controller in step 486 checks to see whether 
the number of bytes read in step 484 is equal to the number of bytes specified by 
the message length field. 

Once the input nnessage data has been parsed out of the incoming message. 
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the floor controllo- takes the iQ)propriate match in response to the message data in 
step 488. This step is described further below with reference to FIGS. 30 and 31. 
Following the message-handling step 488, the floor controller checks in step 490 
to determine whether any response is pending. The floor controller makes this 
determination by cheddng a transactions-in-progress structure which indicates 
whether the floor controller needs to respond to any previous message. If a 
response is pending, the floor controller queues up an appropriate outgoing 
message in the output message queue in step 492. Otherwise, the floor controller 
completes the message processing step 472. 

Referring now to FIG. 30, the message-handling step 488 is shown in more 
detail. The message-handling step begins by verifying that the message 
corresponds to a valid message in step 496. In the preferred embodiment, the 
message includes a cyclical redundancy check (CRC) by which the floor 
controller can determine whether the message is valid or corrupt. Only if the 
message is valid will the floor controller perform any additional message- 
handling steps. The floor controller also parses through the message in step 496 
to determine what type the message is. The message type determines the 
appropriate floor controller action. In die prefened embodiment, the messages 
include a command code which indicates the type of message. 

The first type of message can be one which includes new meter 
inf(Hmation. The floor controller checks in step 498 to determine whether the 
message includes this type of information. Ifthe message includes new meter 
information, the floor controller saves the new meter information locally in step 
500. The floor controller maintains local copies of the meter information in oider 
to minimize the ammmt of traffic on the high-speed n^ork. Because die 
machine meters change so rapidly, forwarding this new meter information on to 
the file server each time one of these m^ers is altered would produce an excessive 
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amount of network traffic on the high-speed netwoilc. Therefore, in the preferred 
embodiment, the floor controller saves this new meter information locally in step 
SOO and only forwards the new information on to the file server after a 
predetermined anK>unt of time has elapsed. 

Another type of message is one which requests data. The floor controller 
checks in step 502 to determine whether the message type is one requesting data. 
Typically, these data requests will be for player tracking information such as 
where a player inserts a card into a card reader whereupon the data 
communication associated therewith sends the identification number encoded on 
the card to the floor controller requesting the player tracking data associated with 
the player identification number If the floor controller detects a data request in 
step 502, the floor controller looks up the requested data in the database on the 
file server in step 504. Also, in step 504, the floor controller marks a response 
pending in the transactions in progress structure to indicate that this requested 
data needs to be sent back to the DCN. As described above, the floor controller 
queues up outgoing messages responsive to the transactions in progress structure. 

Another message type is one used by the floor controller to establish new 
machine addresses. The floor controller periodically checks to determine whether 
any new DCN has been coupled to its associated current loop networks in order to 
assign a unique address to that machine. In step 506, the floor controller checks 
to see whether the incoming message is in response to such a process. If the 
incoming message is in respcmse to a nmchine search, the floor controller assigns 
a new machine address to the responding machine in step 508. The entire 
process of assigning new machine addresses is described below with reference to 

nasi. 

Finally, the floor controller in step 510 handles any miscellaneous 
messages. These miscellaneous messages are used primarily for debugging and 
trouble-shooting the machines. 
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3. Assigning Gaming Device Addresses 
As described above, in the preferred embodiment of the invration, the floor 
controller uses a sh<»thand token representation of the DCN's unique 
identification number to address the DCS. In the preferred embodiment, a single 
byte address is used to address a DCN on any given current loop. This one-byte 
address allows up to 256 DCNs to be supported on any given current loop 
networic. In the preferred embodiment, only 64 such DCNs are connected to a 
single current loop network and therefore the single byte address is more than 
adequate. The single byte address substantially reduces the amount of trafRc on 
the current loop network by reducing the number of bytes from four in the unique 
identification number to one for the shorthand token representation. 

The floor controller is responsible for generating the unique single byte 
address for each data communication node on a given current loop networic. The 
process 508 of assigning unique addresses to the DCNs on the current loop 
networic is shown in FIG. 31. The process begins by defining a range of unique 
identiflcation numbers in step 512. Initially this will be a large range. 

Next, the floor controller sends out a message to all of the DCNs on the 
current loop network in step 514. The floor controller communicates with the 
DCNs by using a standard communication protocol. In the preferred 
embodiment, this protocol deflnes a message format including a destination ID, a 
source ID, a message length, a data packet and a CRC. Other message formats 
could be used as well. Using this format, the floor controller can communicate 
with all of tiie DCNs on the current loop network by using a global destination 
address in the message. This global destination address would indicate to the 
DCNs that this message is intended for all DCNs on the current loop network. 
This global message would include two unique identiflcation numbers that, taken 
together, define the range of unique identiflcation numbers established in step 
512. 
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The individual DCNs thra checks to see whether their unique identification 
nund>er falls within this range. If a DCN's unique identification number falls 
within this range and the DCN does not have an address assigned thereto* the 
£>CN then responds to this global message by sending a reply message in 
response that includes the unique identification number of that DCN. In tte event 
that more than one DCN has a unique identification number that falls within this 
range a network collision will occur and the message will be corrupted. The 
process 508 checks for this condition in step 516. This condition is indicated by 
an invalid CRC in the message. 

In the event of a network collision, the floor controller can limit the range 
of unique identification numbers by repeating step 512 in the hope of eliminating 
this networic contention. 

If the response has a valid CRC, the floor controller assigns a unique 
address to the responding DCN, as identified by the unique identification number 
in the response, in step 518. The floor controller then transmits this address along 
with the corresponding unique identification number in an assignment message to 
all of the DCNs using a global destination address in step 520. The DCNs then 
process this message and in the event that the unique identification number 
included in the n>essage corresponds to the DCN's unique identification number, 
the DCN adopts the address included in the message. Once the DCN has been 
assigned an address in this manner, the DCN will interpret all subsequent 
messages having a destination address equal to tl^ assigned DCN address as 
being directed to that DCN. The above-described address assignment sequence is 
repeated for each of the remaining DCNs on the current loop network in step 522. 
The floor controller continues this process until the entire range of unique 
identification numbers has been covered and no more network collisions occur. 
4. System Monttoring 

Referring now to FIG. 32, the system monitoring step 474 will now be 
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(tesoibed. The floor controller is now responsible for monitoring certain system- 
wide conditions to detennine whether certain events need to occur. The system 
nxmitoring step also handles request for particular machine information. Thus, in 
step 524, the floor controller determines whedier a new request has been placed in 
the data base for such paiticular machine information. If such a request has been 
placed, the floor controller responds to the special request for data in step 526 by 
sending a message to the particular machine requesting the required informadon. 
Once the required information has been received, the floor controller processes 
this information accordingly. 

The floor controller also monitors the locally-stored meter infonnation in 
step 528. If the locally-stored information is changed, the floor controller saves 
the latest information to the data base in step 530. As described above, the floor 
controller saves the meter infonnation locally in oider to minimize the traffic to 
the file server over the high speed network. 

The floor controller also monitors the system for certain event triggers in 
step 532. These triggers can be stored in the data base and fetched by the floor 
controller during its power-up procedures. These triggers indicate if and when 
certain events occur. Examples of event triggers include: the drop period, the 
end-of-day, the bonus period, etc. If an event trigger has occuircd, the floor 
controller handles the event in step 534. 

The handle event step 534 is shown in more detail in HG. 33. The events 
can basically be bifurcated into accounting events and bonusing events. 
Accounting events refer to the data communication activity of the system. The 
accounting events are typically triggered by a certain time of day such as the end 
of day or the drop period. If an accounting event has been triggered, the floor 
controller performs the required data base operations in step 538. This step 
involves updating all of the locally-stored meter information and storing the 
updated meter information into the data base. 
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ITte of&er typs of evmt cm s^gfesnred to as a bonming event. TSie floor 
cositirollejr checks to see whetlh^r Ithe eve&uft is a IboEtusmg evesiit m step 540. The 
bomiiflsmg events cm also be triggeied by the ttiimse of day. For example, the 
bonusmg event may be triggeKed ffirom midnight to 4:00 a.m. on weekdays. These 

5 bonusing periods can be specified in the data base. If the triggesied event is a 

bonusing event the floor controller inserts a corresponding reconfiguration 
message in the outpvt nrtessage qmm in step 542. The reconifiguration message 
inclnndes a reconifiguration command that is sent to an appropriate machine. The 
machine, upon receiving the seconfigmation command, reconfigures its payout 

10 schedule in accordance with the received seconfiguration command. According 

to the invention, there are mmany different reconfiguration commands to implement 
a multiplicity of different bonusing events. One reconfBguration command 
specifies that the machine should reconOgure its payout schedule to be a multiple 
of its default payout schedule. This reconfiguration comsnand can also specify 

15 that the multiple payout schedule should be limited to a predetermined percentage 

of the coins in. This sm>niguration command can further specify that the 
multiple payout schedule should be limited to only when the maximum coins are 
played. This reconfiguration command can fuither specify that the multiple 
payout schedule should be limited to payouts in a specified range. This 

20 reconfiguration command can also specify the multiple payout schedule should 

payout only when a predetermined level of player activity is reached. 

Another reconfiguraltion command allows any number of machines on the 
network to be com£)ined in a common jadcpot having a cosmnon jackpot payout 
schedule, wl^rein the reconfiguration command meconfigures the selected 

25 machines to payout in accordance with tte common jackpot payout schedule. In 

this case, the reconfiguration message would be queued up for each of the 
selected machines to be combined in a common jadcpoL One example of a 
common jackpot is a progressive jackp^. Unlike the prior art progressive jackpot 
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systenos, however, Jfes progEtessive jackpot accoirding to the imvention is not 
liimted to a predeteraiined nsnmobsr olF snachines. In the prior art progressive 
jackpot systems, a baak oIF macMnes are connected to a common progiessnve 
jackpot controller and nwoly those naachines can be incliBded in the progressive 
jackpot. In contrast, any machine on the network, including those connected to 
other floor controllers can be combined into a common progBiessive jackpot. 
Moreover, the numbsr of progressive jackpots is not limited by the number of 
floor controllers since one floor controller can manage more than one progressive 
jacIqKjt. 

Another rcconfiguratnon command permits tfes system to implemient so- 
called "automatic mystery jackpots." These "mystery" jackpots allow a machine 
to payout a mystery jackpot even when a jackpot was not won. Instead, the 
reconfigurataom command can specify that the mystery jackpot is to occur after a 
certain number of coins, a certain number of handle pulls, or a variety of other 
conditions specified by the reconfiguration commands. These mystery bonuses 
provide the casino with another way to induce additional gaming activity. 
5. BC3WUS Control 

Referring now to HG. 34, a method 550 for controlling the conditioms 
under which the above-dSsscribed bonus activities are activated is shown. It is 
essential for the system to have complete control over the amount and conditions 
under which a bonus is paid out in order to insure the profitability of the bonusing 
system. The method 550 described below provides the required control. 

•mils method 550 begins in step 352 by disabling or turning off the bonuses 
in the imdivBdual machines. This is accomplished by sending a message to the 
individual EX3*Js to turn olff or deactivate bonusing. Next, the floor controller 
Buonitors the activities of the individual machines connected thereto. This step 
includes monitoring the coins in and bonuses paid for the individual machines, as 
described above. In step 556, the floor controller modifies a bonus pool by a 
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piredeteirmmed jpescesitage of &U corns pkyed. The bosius poo! is esseEdally a 
pool of mosfiett2iry sesoiiurces uSiM can be allocated for bonus awasxis. In tthe 
pinsfeinred embodiment, a predetenmned percentage of the monetary valise of the 
coins played are added to the bonus pool. Also in this step» any bonuses paid by 

S the gamiRig devices are also measured and subtracted from the bonus pool. The 

use of the bonus pool will become more apparent when the other steps are 
described hereinbelow. 

In step 3S8» the floor controller determines whether or not bonusing is 
active. If bonusing is active, the ffloor controller next determines whether the 

no bonus pool amount fiias dropped below a predetermined Hninimum level called the 

"tum-ofT level in 560. This minimum amount or floor can be set by the casino 
and provides a buffer to account for large bonus awards and/or multiple bonus 
awards that could cause the bonus payout to exceed the bonus pooL Therefore, if 
the bonus pool drops below the turn-off level, the method 550 branches back to 

15 step 332 and turns off bonusing* As will described further below, the bonusing 

remains off until such time as the bonus pool builds up past another minimum 
level called tlte "tum-on" level. 

Returning to step 558, if the bonus is currently not active, the floor 
controller determines at step 562 whether the bonus pool has reached a 

20 predetermined tum-on level. This tum-on level can also be set by the casino and 

provides a buffer above the tura-oi^ level to insure that the bonusing does not 
behave erratically, i.e., bonusing rapidly switching between on and off. If the 
bonus pool is nc^ above the tum-on level, bonusing is again turned off in step 352. 
If the bonus pool has reached the tum*on level, the floor controller checks 

25 to see whether other bonus conditions are m^ at step 564. These bonus 

conditions can include, but are not limited to, a minimum period of time since the 
last bonus activation, a minimum level of play in the time period prior to the 
bonus pool reaching the turn on level, a predetennined tim^ of day, or other 
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psedeSemniiniedl coBditioms. These conditioiiis gnve (the csisisio additiosna! cositrol 
over tlte boanssing pffosiK>i5ons. If ths conditions are ml met, ihe ra^thcd 550 
bramcto back fto step 552 where the bomBsimg is again Orojed off. Rf, however, 
the cceditaoBiS are mttet in step 564, the bonus is turned on at step 566 and the 
method 550 branches to step 554 where the machine activity is again monitored. 

In the preferred embodiment, the n^thod 550 is embodied in software that 
is exeaited by each of the floor controllers in the system. These floor controllers 
are then responsible for activating or deactivating the bonwsing for the individual 
machines connected thereto. The system allows the floor controller to have 
multiple bonus pools and to have certain of the machines associated with a given 
bonus pool Thus, the 

floor controller can implement multiple bonusing promotions simultaneously. 

This system also allows for machines connected to different floor 
controllers to be combined into a single bonusing promotion. In this case, one of 
the floor controllers assumes primayy responsibility for managing the bonus pool 
while the other floor controllers act as intermediaries between the prinwy floor 
controller and the machines connected to the other floor controllers. Thus, the 
system according to the invention allows for much greater flembility in ranning 
bonusing promotionals than heretofore possible. Prior art systems- required 
certain predetermined machines to be connected into a bank for any given bonus ' 
award such as a progressive bonus. The system according to tl^ invention allows 
any Hnachine in the casino to be combined in a bonus type situation. The system 
also insures that the bonusing promotional will opemte substantially in the black, 
i.e., th@ bonus pool is greater than the bonus payouts. 

Having described and illustrated the principles of th® invention in a 
prefesred emtoodiment thereof, it should be apparent that the invention can be 
modifled in Mrangemient and detail without depaxuing from such principles. For 
example, although an Ethemet network was described in the preferred 
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embodiment of the invention, other high-speed networks such as wireless 
networks could be used in place thereof. I claim all modifications and variation 
coming within the spirit and scope of the following clainis. 



W09&12262 



PCtA)S9S/11610 



70 
CLAIMS 

1 . A method of operating gaming devices interconnected by a 
computer networic to a host computer comprising: 

sending a reconfiguration conunand from the host computer to a gaming 

device over the network; 

receiving the reconfiguration conunand at the gaming device; and 
reconfiguring the gaming device responsive to the received reconfiguration 

conunand, wherein the gaming device reconfigures its payout schedule in 

accordance with the received reconfiguration conunand. 

2. A method of operating gaming devices according to claim 1 
wherein the step of reconfiguring the gaming device includes reconfiguring the 
payout to be a multiple of a default payout schedule. 

3. A method of operating gaming devices according to claim 2 
wherein the step of reconfiguring the gaming device includes reconfiguring the 
payout to be double the default payout schedule. 

4. A method of operating gaming devices according to claim 2 
wherein the step of reconfiguring the ganung device includes limiting the multiple 
payout schedule to a predetermined percentage of the total gaming device handle. 

5. A method of operating gaming devices according to claim 2 
wherein the step of reconfiguring the gaming device includes limiting the multiple 
payout schedule to a predetermined percentage of the coins in. 
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6. A method of operating gaining devices according to claim 2 
wherein the step of reconfiguring the gaming device includes limiting the multiple 
payout schedule to payout only when maximum coins are played. 

7. A method of operating gaming devices according to claim 2 
wherein the step of reconfiguring the gaming device includes limiting the multiple 
payout schedule to payout only when an award falls within a predetermined 
range. 

8. A ntethod of operating gaming devices according to claim 2 
wterein the step of reconfiguring the gaming device includes limiting the multiple 
payout schedule to payout only when a predetermined level of activity is reached. 

9. A method of operating gaming devices according to claim 1 further 
comprising: 

selecting two or more gaming devices on the netwoiic to be combined in a 
conunon jackpot having a common jackpot payout schedule; 

wherein the step of sending a reconfiguration conmiand includes sending a 
reconfiguration conunand to each of the selected gaming devices; and 

wherein the step of reconfiguring the gaming device includes reconfiguring 
the seleaed gaming devices to payout out in accordance with the common jackpot 
payout schedule. 

10. A method of opo^ting gaming devices according to claim 9 
wherein the step of reconfiguring the gaming device includes reconfiguring the 
selected gaming devices to payout out in accordance with tte common, 
progressive jackpot payout schedule. 
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11. A method of operating gaming devices according to claim 1 
wherein the step of sending a reconfiguration command includes sending a 
reconfiguration command describing a progressive jackpot payout schedule to 
each of the selected gaming devices. 

12. A method of operating gaming devices according to claim 1 
wherein the step of reconfiguring the gaming device includes reconfiguring the 
payout to be an automatic mystery payout. 

13. A method of oporating gaming devices according to claim 12 
wherein the step of sending a reconfiguration conunand from the host computer to 
a gaming device via the netwoik includes sending a reconfiguration command 
specifying tte playing conditions under which the automatic mystery payout will 
payout. 

14. A method of operating gaming devices according to claim 1 
wherein the step of sending a reconfiguration command from the host computer to 
a gaming device via the network includes: 

detecting the time of day; and 

sending the reconfiguration command from the host computer to a gaming 
device via the network when the detected time equals a predetermine time. 

15. A method of operating gaming devices according to claim 14 
further comprising inputting the predetermined time on the host computer. 

16. A method of operating gaming devices according to claim 1 further 
comprising: 
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sending a status request from the host computer to a gaming device; and 
transmitting accounting data from the gaming device to the host computer. 

17* A method of operating gaming devices according to claim 16 
frurther comprising: 

detecting a player associated with a gaming device; 

sending a player identification number from the gaming device to the host 
computer over the network; and 

associating the accounting data with the player identification number for 
player tracking puxposes. 

18. A method of operating gaming devices according to claim 17 
further comprising: 

sending a conunand including a credit amount from the host computer to 
the gaming device associated with the player; and 

crediting the gaming device with the credit amount responsive to receipt of 
the conmiand to provide cashless play. 

19. A method of operating gaming devices interconnected by a 
computer network to a host computer comprising: 

detecting a player associated with a gaming device; 

sending a player identification number from the gaming device to the host 
computer over the network; 

sending a status request from the host compute to a gaming device; 

transmitting accounting data from the gaming device to the host computer 
over the same network; and 

associating the accounting data with the player identification number for 
player tracking purposes. 
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20. A method of operating gaining devices according to claim 19 
further comprising reconfiguring a gaming device over the network, wherein the 
reconfigured gaming device modifies a jackpot payout schedule associated 
therewith. 



21. A method of operating gaming devices interconnected by a 
computer netwoik: to a host computer, the method comprising: 

detecting a player associated with a gaming device; 

sending a reconfiguration command from the host computer to the player's 
gaming device via the network; 

receiving the reconfiguration command at the player's gaming device; and 

reconfiguring the player's gaming device responsive to the received 
reconfiguration command, wherein the player's gaming device reconfigures its 
payout schedule in accordance with the received reconfiguration command. 

22. A method of operating gaming devices according to claim 2 1 
wherein the step of reconfiguring the player's gaming device responsive to receipt 
of the reconfiguration conunand includes adding an extra bonus to the payout 
schedule. 



23. A method of operating gaming devices according to claim 2 1 
wherein the step of reconfiguring the player's gaming device responsive to receipt 
of the reconfiguration conunand includes adding a progressive jackpot to the 
payout schedule. 



24. A method of operating gaming devices according to claim 2 1 
further comprising determining whether the player satisfies a predetermined 
criteria. 
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25. A method of operating gaming devices according to claim 24 
wherein the step of determining whether the player satisfies a predetermined 
criteria includes determining whether the player is a member of a club. 

26. A method of operating gaming devices according to claim 24 
wherein the step of determining whether the player satisfies a predetemiined 
criteria includes determining whether the player has reached a predetermined 
level of activity. 

27. A method of operating gaming devices according to claim 26 
wherein the step of determining whether the player has reached a predetermined 
level of activity includes: 

detecting the level of activity and the time period over which the activity 
occurs; and 

transmitting the activity level and the time period to the host computer via 
the netwoiic. 

28. A system for operating a plurality of gaming devices having serial 
interfaces, the system comprising: 

a host computer, 

a networic interconnecting the gaming devices to the host computer, 
means within the computer for transmitting a reconfiguration conunand to a 
gaming device; 

means within each gaming device for receiving the reconfiguration 
conunand transmitted to the gaming device; and 

means within each gaming device for reconfiguring the gaming device 
responsive to the received reconfiguration conunand, wl^rein the 
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gaining device reconfigures its payout schedule in accordance with the received 
reconfiguration conunand. 

29. A system for operating a plurality of gaming devices according to 
claim 28 comprising: 

5 means within each gaming device for identifying a player associated with 

each gaming device; 

means within each gaming device for sending the player identity from the 
player's gaming device to the host computer via the netwoiic; and 

means within the host computer for receiving the player identity. 

*0 30. A system for operating a plurality of gaming devices according to 

claim 29 wherein the means within the computer for transmitting a 
reconfiguration command to each one of the gaming devices includes means 
within the computer for transmitting a reconfiguration command to the player's 
gaming device responsive to the received player identity. 

* 5 3 1 . A system for operating a plurality of gaming devices according to 

claim 28 wherein the host computer comprises at least one floor controller 

32. A system for operating a plurality of gaming devices according to 
claim 31 whmin the host computer comprises a file servw. 

33. A system for operating a plurality of gaming devices according to 
20 claim 32 wherein the network comprises: 

a current loop network coupled between the floor controller and a plurality 
of associated gaming devices; and 

a high-speed netwotk coupled between the floor controller and the file 
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server. 

34. A system for operating a plurality of gaming devices according to 
claim 33 wherein the network includes a plurality of current loop networks, and 

wherein the floor controller includes a communication board having a 
plurality of current loop interfaces for coupling to the plurality of current loop 
networks, the corrununication board having a plurality of microprocessors, each 
microprocessor responsible for the transmissions on an associated current loop 
network, the conmiunication board including a current loop driver interposed 
between the plurality of microprocessors and the plurality of current loop 
networks. 

35. A system for operating a plurality of gaming devices according to 
claim 28 wherein the means within each gaming device for receiving the 
reconfiguration conunand transmitted to the gaming device comprises a data 
corrununication node coupled to the network and coupled to the serial interface of 
the associated gaming device, wherein the data conununication node monitors the 
transmissions on the network and determines which transmission is transmitted to 
the associated gaming device. 

36. A system for operating a plurality of gaming devices according to 
claim 35 wherein the data conununication node includes: 

a coritroller; 

a serial machine interface coupled between the controller and the serial 
interface of the associated gaming device for receiving data from the associated 
gaming device and transmitting the received reconfiguration conunand to the 
gaining device. 

37. A system for operating a plurality of gaming devices according to 
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claim 28 including a non-volatile memory within each gaming device for storing a 
unique gaming device identification number to uniquely identify the gaming 
device on the network. 

38, A system for operating a plurality of gaming devices according to 
S claim 37 including: 

means within each gaming device for reading the imique gaming 
identification numben and 

means within each gaming device for transmitting the unique gaming 
identification number to the host computer. 

* 0 39. A system for operating a plurality of gaming devices according to 

claim 37 including a machine configuration circuit for identifying the type of 
gaming device. 

40. A method of providing feedback to a user inserting a user 
identification card having a unique user identification number encoded thereon 
1 5 into a gaming device, the method comprising: 

receiving the card into a card reader opening; 
sensing the number on the card; 

determining whether the sensed number is a valid identification number. 

and 

20 providing feedback to the user adjacent the card reader opening, the 

feedback comprising a positive feedback signal if the sensed number is a valid 
identification number and a negative feedback signal if the sensed number is not a 
valid identification number. 



41. A method of providing feedback to a user according to claun 40 
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wherein the step of providing feedback to the user adjacent to the card reader 
opening includes providing visual feedback around the card reader opening. 

42. A method of providing feedback to a user according to claim 41 
wherein the step of providing feedback to the user adjacent to the card reader 

S opening includes providing a first visual signal having a first color if the sensed 

number is a valid identification number and a second visual signal having a 
second color, different from the fust color, if the sensed number is not a valid 
identification number 

43. A method of providing feedback to a user according to claim 42 

10 wherein the step of providing a first visual signal having a first color if the sensed 

number is a valid identification number includes providing a first visual signal 
having a green color if the sensed number is a valid identification number; and 

wherein the step of providing a second visual signal having a second color 
if the sensed number is not a valid identification number includes providing a 

IS second visual signal having a red color if the sensed number is not a valid 

identification number. 

44. A method of providing feedback to a user according to claim 42 
wherein the step of determining whether the sensed number is a valid 
identification number includes providing a third visual signal having a third color, 

20 different from the first and second colors, during the pendency of the determining 

step. 

45. A method of providing feedback to a user according to claim 41 
wherein the step of providing feedback to the user adjacent to the card reader 
op^iing includes actuating a plurality of light emitting diodes arranged around the 
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card tcadet opening. 

46. A method of providing feedback to a user according to claim 40 
wherein the step of determining whether the sensed number is a valid 
identification number includes comparing to a plurality of predetermined valid 

5 identification numbers. 

47. A card reader having user feedback which reads a user 
identification card having a user identification number encoded thereon 
comprising: 

a bezel defining a card reader opening; 
means for sensing the user identificaUon number on the card; 
means for determining whether the sensed number is a valid identification 
number; and 

means for providing visual feedback to the user adjacent the card reader 
opening, the visual feedback comprising a first visual signal if the sensed number 
is a valid identification number and a second visual signal if the sensed number is 
not a valid identification number. 

48. A card reader having user feedback according to claim 47 wherein 
the means for providing visual feedback includes a plurality of light emitting 
diodes disposed around the card reader opening. 

49. A card reader having user feedback according to claim 48 wherein 
the light emitting diodes include dual light emitting diodes for producing both the 
first and the second visual signals. 



10 



15 



50. A card reader having user feedback according to claim 47 wherein 
the user identification card includes a plurality of holes which encode the user 
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identification number and which are arranged in colunms and wherein the means 
for sensing the user identification number on the card includes an optical card 
reader. 

51 . A card reader having user feedback according to claim SO wherein 
the optical card reader includes: 

a plurality of light emitting diodes disposed on a first side of the card reader 
opening; and 

a plurality of photodetectors disposed on a second side of the card, opposite 
the first side for detecting the light emitted by the plurality of light emitting 
diodes. 

52. A card reader having user feedback according to claim 51 wherein 
the light emitting diodes and the photodetectors are arranged in opposing pairs for 
detecting the holes of a respective colunm. 

53. A card reader having user feedback according to claim 47 further 
including: 

means for detecting the orientation of the card; and 

wherein the means for determining whether the sensed number is a valid 
identification number transposes the sensed number according to the orientation 
detected by the detection means. 

54. A card reader having user feedback according to claim 47 further 
including first and second guide members disposed on opposing lateral sides of 
the card reader opening for guiding a user identification card therealong. 

55. A method of operating gaming devices interconnected by a 
conq)ut» network to a host computer comprising: 
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monitcmng the activity of the gaming devices; 

detecting the amount of money played pn the gaming devices; 

allocating a predetemiined percentage of the money played to a bonus pool; 

detemiining the level of the bonus pool; and 

activating a bonus payout table in a gaming device when the bonus pool 
level exceeds a turn-on level. 

56. A method of operating gaming devices interconnected by a 
computer networic to a host computer according to claim 55 comprising 
deactivating the bonus payout table when the bonus pool falls below a tum-off 
level. 

57. A method of operating gaming devices interconnected by a 
computer network to a host computer according to claim 55 comprising: 

determining the time period since the last bonus table activation; and 
deactivating the bonus payout table when the time period exceeds a 
minimum period of time. 

58. A method of operating gaming devices interconnected by a 
computer network to a host computer according to claim 55 comprising: 

determining the level of play for a gaming device; 
deactivating the bonus payout table in the gaming device when the level of 
play falls below a predetermined level. 

59. A method of operating gaming devices interconnected by a 
computer network to a host computer according to claim 58 comprising: 

detomining the time of day; 

deactivating the bonus payout table when the tifm of day is not within a 
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predetermined period of time. 

60. A method of operating gaming devices interconnected by a 
computer network to a host computer according to claim 55 comprising: 

detecting the amount of money paid out as bonuses on the gaming devices; 
modifying the bonus pool by the amount of money paid out as bonuses; 
determining the level of the bonus pool; and 

deactivating a bonus payout table in a gaming device when the bonus pool 
level falls below a tum-off level 

61 . A method of operating gaming devices interconnected by a 
computer network to a host computer according to claim 60 wherein the tum-on 
level is above the turn-off level. 
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